Hi Patrick,

When I get to the point of "mathematically correct gray soup of text", 
I'll be happy! Then I'll start thinking on more advanced solutions.

Cheers,
Juan Vuletich
www.jvuletich.org

Patrick Georgi wrote:
> Juan Vuletich schrieb:
> "
> I want high quality rendering on any Display, regardless of size or 
> pixel resolution. Therefore, I need complete independence of those 
> Display properties. The programmer must never deal with the concept of 
> pixel. The GUI is thought at a higher level. All the GUI is 
> independent of pixel resolution. All the rendering is anti aliased. 
> But in order to be able to render equally well on very high resolution 
> as on medium resolution devices, the objects to be rendered (i.e. 
> morphs) must be specified in a way that doesn't depend on the 
> resolution of the target device at all. The ultimate way to do this is 
> by thinking of them as continuous functions. This applies to geometric 
> shapes, but also to digital images (photos) and textures.
> "
>
> This will pose a problem with fonts - it was one of Fresco's 
> (www.fresco.org) bigger issues when it came to the drawing model, as 
> Fresco used a device independent layout, too.
>
> Bitmap fonts are pixel based, so those wouldn't work properly (how to 
> translate a font pixel into a pixel-less world in a resolution 
> independent way, so that the font always looks good?)
>
> Vector fonts have the issue that their features only incidentally will 
> align to the pixel grid of your target device (when it comes down to 
> rendering). (and compared to drawing, the human brain seems much more 
> sensitive to that when it comes to text, maybe because it's more 
> necessary detail per cm^2 than for the average drawing)
>
> Either, you just handle fonts like everything else and anti-alias them.
> See Acrobat Reader 5 (or so) with small fonts to see how it looks - 
> you'll get a mathematically correct, unreadable grey pixel soup.
>
> Or you take hinting into account - but that forces you to think about 
> a pixel grid again (hints help align glyph features to some grid), and 
> you'll have to choose, which grid to take.
>
> Unfortunately, you can't just defer that decision until it's rendered 
> to the device, as hinting can (to some extend) change the size of a 
> glyph, depending on its location and the target resolution (and 
> neighbor glyphs, I think, so you couldn't just render them one-by-one 
> to given locations).
>
> Usually, the impact is minor, but you might get to the situation where 
> a group of glyphs in a line get small enough due to changes in hinting 
> that another word fits into their line (when it missed it before by 
> just a minimum amount) and so you get to rewrap the whole text from 
> that point (or ignore that by pinning text to fixed locations in some 
> way, making that a special case)
>
> Anyway, when taking text into account, more thought might be necessary 
> on that move.
>
> I'm very much in favor of a truly device independent graphic 
> subsystem, though.
>
>
> Regards,
> Patrick Georgi
>
>
>