[fitz-dev] Re: MuPdf / Fitz

[Tor Andersson]

Raph Levien <raph at casper.ghostscript.com> wrote:

> > First, where does the name Fitz come from?
>
> It's an Anglo-Norman prefix meaning "son", but often used to mean
> "bastard son of". Fitz is the bastard son of Libart and the Ghostscript
> graphics library.

Ah. Fils. Son. Fitzpatrick. Should've known.
Some old geezers in Sweden are called Frits.
Some are called Rune.
Not very common names anymore though.

> Actually, there's thought of calling it "Libart 2" or somesuch, because
> there's pretty good brand name recognition.

Yech. I like quirky names. I have no understanding for people who
think that Ogg Vorbis is a bad name... and they think something like
Emm-Pee-Three is better?

> > Oh, and your hyphenation code breaks down in mysterious ways when fed
> > patterns for Italian and Latin languages. I think something fishy is
> > going on with that statemachine, I never really understood how it works.
>
> I'm not too surprised that there are problems. I never tested on
> dictionaries other than the English. There are also issues with
> character sets and case conversions.

Well, I fixed the latter two. But now I have another implementation that
appears to work for most other languages... it just needs cleaning up,
enabling unicode charsets and turning into a decent library.

> > Would it be possible to shift the font definition logic into another
> > layer so that all Fitz works with is a collection of glyphs and an
> > encoding vector of size 256? How do CID fonts work? I haven't had time
> > to investigate.
>
> Well, restricting to size 256 sounds like a pretty big lose. It _is_
> reasonable, I think, to treat fonts as integer-subscripted arrays of
> glyphs, and have the next level above deal with the encoding issues.

Yep, but then the PDF backend will have to deal with subsetting the fonts.
In postscript we can always cheat and use glyphshow...
If the layer above already deals with encoding issues, having to subset
a font there is not that a big step. And doing it one layer closer to the
application means that it can probably make a more intelligent choice as
to which glyphs go in which subset.

> Among other things, CID fonts provide an answer to certain problems
> that come up in CJK unification. For example, a font can store both
> the simplified and traditional Hanzi for the same Unicode code point,
> with different CID's. Then, you can have different Unicode->CID
> CMap's, one for traditional and one for simplified.

That's a good idea.

/tor