MuPdf / Fitz

[Tor Andersson]

Incoherent Rambling Thoughts on Fitz

For background, check my last advogato diary post,
and the pages on my personal Wiki:

http://www.advogato.org/person/tor/diary.html?start=4
http://spacecow.df.lth.se/wiki.cgi/AeKit
http://spacecow.df.lth.se/wiki.cgi/LibRune
http://spacecow.df.lth.se/wiki.cgi/RhoadsThor

----

What I Want from Fitz

* Resolution and device independent rendering of graphics + text

* Good for both on-screen display and generating printable files

* High-quality text: subpixel-positioned unhinted fonts

* Good font handling, with all the meta information necessary for typography:
kerning, contextual glyph replacement, ligatures, etc...

* Be able to drive a GUI toolkit: responsive speed.

* API should fit with: interactive graphics and text editing as well as
a foundation for a toolkit.

----

Immediate mode -- for old-style procedural (Quickdraw/OpenGL) rendering

Editable display tree with automatic re-rendering -- when the app can be well
integrated with Fitz' model

Fonts ... personally I'd just skip hinting and be well rid of that extra
layer of complexity. But for 1-bit rendering on low-res devices I suppose
that it is a must. How common are they? Is it worth it? We still need
sub-pixel correct widths when calculating, line breaks should not be
dependent on output device/resolution.

As for substituting fonts, my opinion is that it's a waste of time
to put this in Fitz. If necessary, it's a job for Fontconfig or an external
library. Fitz should deal with scalable outlines only. Other tools can deal
with generating font outlines from various formats.

If an application needs a certain font for good typesetting, a poor
substitute is not an option. Look at TeX, it thrives on its predictability. If
the same document were to generate different output depending on where it
was run through TeX people would be most unhappy.

Are we sure we want to deal with supporting all the old drawing apis as
backends? (GDI, Quartz, Quickdraw, X11)
Sure, providing hooks for old renderers is nice in theory, but dealing
with all the various quirks in font handling could prove to be more trouble
than we are willing to put up with. But then, we could do our own font
management and push bitmaps. XRender is going in the right direction,
and is still young enough to fix if problems arise.

Do we use floats or fixed point math?

Analytic AA or supersampled? Supersampled is conceptually easier, but
degenerate cases (horiz/vertical) lines are rather common.

Which color space internally? Gamma 1.0 is good for AA calcs, but when
using 8-bit color components you lose on precision.

What is "stroke adjustment"? I never quite understood that.

I presume Fitz will be written in ANSI C.

We should really really really get fonts right. It's one of the messiest
problems in systems today. Fontconfig goes a long way to solve some issues,
but is not panacea.

/tor