MuPdf / Fitz

Antony Courtney antony at apocalypse.org
Wed Jul 10 19:17:18 PDT 2002


Hi Tor,

Your work on MuPdf and CharCoal and AeKit look VERY cool.  I'm going to 
try to download and play with one or all of them after I finish writing 
this message.

I'm intrigued and delighted to see that you are interested in functional 
languages and that you want to use a real vector graphics model (with 
great font support) as the basis for a GUI toolkit.

I got in touch with Raph a few weeks ago because I'm exploring 
"genuinely functional" approaches to GUI programming for my Ph.D. 
thesis.  I really need a good, fast, freely available vector graphics 
library as the basis for my work, and I'm willing to roll up my sleeves 
and hack to make that happen.

Doing something really good and complete is a BIG task; It would be 
great if we could figure out how to work together to produce one good, 
coherent foundation-level vector graphics library instead of a bunch of 
partial solutions.

If you're interested in reading a bit about my approach to functional 
GUIs, here is a draft of a paper that was rejected from UIST just recently:
	http://www.haskell.org/fruit/functionally-modeled-guis.pdf
(The paper has a lot of flaws, and only explores a really trivial 
example in any depth, but it should give some of the basic flavor of my 
work.)  There are also some slides on my functional API for vector 
graphics available from the Haven web page, if you're interested in the 
lower-level stuff.

Your wish list for Fitz looks good to me.  A couple of quick responses:

> 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.

Interesting.  This is where I show my ignorance and lack of experience 
with the nitty gritty of font rendering.  I thought the whole motivation 
for font hinting was to ensure that fonts still look good when rendered 
at small point sizes on video displays.  But I guess you and Raph seem 
to think that sub-pixel accuracy and anti-aliasing mitigate the need for 
hinting?  I'm sure you are both right, but if either of you has any 
pointers to pages on this debate (particularly if it has side-by-side 
renderings for comparison!) that would be great.

Also, a terminology question:  What do we mean when we say "sub-pixel 
accuracy"?  Do you mean doing all of the calculations in floating point 
or fixed point and only rounding to pixel coordinates when rendering? 
Or do you mean doing sub-pixel rendering in the sense described on the 
FreeType page, which only works on LCD screens?  (Or is there some other 
sense I'm not considering.)

> 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.

I agree.

But I still think we might want to at least provide some simple way for 
an app to ask for a non-specific fonts, perhaps by just guaranteeing 
that some font names (like, say "System", "Monospaced", "Serif" and 
"Sans") will always be available.

> 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.

I think we want to try (or at least, not prohibit) people from using 
calls to optimized native renderers for basic stroke and fill type 
stuff.  I didn't intend that item to imply that we would make any 
attempt whatsoever to try and do some fancy impedance matching between 
good font handling in Fitz and whatever the native system supports.

> 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 defer to Raph on all of the above.  I simply don't have the experience 
implementing rendering to have an opinion.  Yet!
> I presume Fitz will be written in ANSI C.

Amen.

> 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.

Sounds good to me.

	-antony

-- 
Antony Courtney
Grad. Student, Dept. of Computer Science, Yale University
antony at apocalypse.org          http://www.apocalypse.org/pub/u/antony



More information about the fitz-dev mailing list