[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: About TeX as printing engine [Re: Fwd: Re: Application Ideas]
From:       Kuba Ober <kuba () mareimbrium ! org>
Date:       2001-08-04 14:43:13
[Download RAW message or body]

Most of the algorithms that TeX uses are pretty simple and they are well 
documented in Donald E. Knuth's (DEK's) TeXbook.

Actually, most people like to believe there's a lot hard-to-understand magic 
going on in TeX. For all of you not fortunate enough to have a copy of 
TeXbook, here's a short run-down of topic-important TeX's features, all of 
which can be quite easily implemented in Koffice and other apps by inheriting 
and tweaking with Qt 3 rich text control. These are really *simple* 
techniques that are *well documented* by DEK. Actually I think that it's 
their simplicity, elegance and good output that makes people believe that 
they must be complicated.

1. Whole paragraph typesetting on a low level - tries different reneditions 
of same paragraph, and chooses the best one. I imagine that typical 
`handmade' rich-text renedition is done in per-line mode.

2. Multipage typesetting of already-typeset paragraphs. Tries different 
reneditions of placing paragraphs on pages and splitting them between the 
pages, and chooses the best one.

3. Usage of *decent* coordinate units. TeX uses sp's (scaled points, there 
are 65536 sp in 1pt, 72.27pt in 1in, and 25.4mm in 1in) that are in nanometer 
range (about 5*10E-9 m). That means that there are about 100sp's per one 
wavelength of visible light, meaning that by joining black and white-filled 
boxes in TeX you can design diffraction gratings ;-). Koffice currently uses 
600dpi resolution (4*10E-5m).

4. Integer arithmetics is used to work on coordinate units. Those arithmetic 
functions are designed to be portable, and their rounding errors are 
controlled so that they yield same results independently on what CPU you 
execute them, as long as the CPU and the whole system act up to their 
specifications (not failing due to overclocking / overheating).

5. Effective yet simple hyphenation done using hyphenation tries. You can 
read more about tries (they are data structures) in Knuth's TAOCP (The Art of 
Computer Programming).

6. Using of abstract, cachable representation of fonts. TeX works with glyph 
bounding boxes, ie. it doesn't need to `see' the outline of the glyphs it 
uses until it's time to render them. It completely detaches the typesetting 
from any hardware, be it printer or screen display. 

7. Glyph outline sizes are represented in sp's and stay fixed for a given 
font. That means that if the text was set in an ult1mo foundry face that 
nearly everybody has got on their *nix machines, all the breaks (line- and 
page-) are same independently of architecture - CPU, screen dpi, printer dpi, 
blahblah.

8. The renderer is the only place to use the glyph shapes (outlines). The 
renderer itself doesn't need to know anything else but glyph shapes and their 
positioning, together with any bitmaps and vector images on the page.

9. Again, (3) and (6) mean that how the page is typeset doesn't depend *at 
all* on what output devices are used. That's what typography is meant to be. 
I should mention that neither koffice nor ms-office has that kind of device 
independency. Koffice is a little closer to it though, because it nowadays 
uses 600dpi for glyph placement independently of output device dpi. Try 
printing your text at 600, 300 and 150 dpi devices in ms-office - you'll 
likely vreak havoc in linebreaks etc. In TeX, nothing changes, because when 
the time comes to do rendering, all glyphs are pre-placed.

10. Most of the kde-related font problems, and how ugly the koffice output 
looks, is related to the fact that Qt really *needs* to have access to 
scalable fonts that you use. Many (too many) distributions are using xfs (X 
font server) as the only font source on their X-windows installations. Xfs 
doesn't provide any physical access to the fonts and their real (as opposed 
to device-dependent) glyph sizes. I'm writing a FAQ how to remedy this 
situation on typical distributions like RedHat without possibly recompiling 
the X server. I'm also writing a Qt utility to fix those font problems 
automatically, providing a capable-enough xserver is present.

I would like hereby to declare what I wish for all kde-developers to 
understand: good looking text in kde and Qt applications is just a matter of 
positive thinking, a little work, and not considering magic what isn't magic 
at all.

I should also emphasize that at least RedHat, since their 6.x release, is 
constantly breaking the printed output of Qt applications, for reasons beyond 
my comprehension, and that they know how to fix it, but they think they have 
more important stuff to do instead. Ugh, poor world we live in.

Eh, and I should also emphasize that there's nothing wrong per se with Qt/KDE 
font rendering accuracy. It's at least as good (or as bad) as it is on 
windows. That most people have their machines heavily misconfigured (by 
virtue of distro-makes, mostly), is the sad truth that adds to false belief 
that Qt/KDE is font-broken... It isn't, but down-to-earth users don't have 
time nor incentive to delve in those issues and fix them themselves...

Eh2, and yes, a little Qt-tweaking is in order for it to use sp's in font 
rendering ;-)

Cheerz,
Kuba
 
>> Visit http://master.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

[prev in list] [next in list] [prev in thread] [next in thread]