Re: Dia, Pango, Postscript. Argh.



Le Wed, Jun 26, 2002, à 04:06:13PM -0500, Lars Clausen a écrit:

On Wed, 26 Jun 2002, Cyrille Chepelov wrote:

At first, it seems [paps] embeds bitmaps into Postscript, and calls it
"rendering Pango text into Postscript". In fact, it does much better (not
as good as possible, but much better nonetheless): it uses FT to extract
the font outlines, and generates one (copy of) outline per instance of
the glyph.  It makes no attempts to compress or commonalise anything;
still, the resulting postscript is resolution-independent.

Except that it lose all the hinting that goes into a real font and makes it
readable at small sizes.

Is it really lost, or simply described into the
PangoGlyphString->glyphs[i].geometry structure?

    - we also generate custom fonts out of the outlines, using the
Postscript facilities. These fonts will be peculiar:
    * they will have funny names
    * they will have holes (only glyphs actually used will be embedded)
    * they will have a very strange encoding (or suitable concept)

Why should they have other names than what the original fonts have?
This is basically dumping the font into the file, but only with the glyphs
that we need.

Two good reasons
        - they aren't the original fonts, since we stripped from them the
"useless" glyphs.
        - we have no clue what their original Postscript name is. If we had,
we'd just (IMO) put it and let ps2ps do the inclusion if the user wishes so.

We don't define a font, because that way we don't need to deal with
defining ligature and kerning tables and all that crap -- we extract from
the PangoLayout a bunch of "put this glyph -- by the way, here's the
definition -- at this position this scale; now put this glyph, same
scale, at this position; now put ...". We get rid of ps-utf8.[ch] (but
write something faintly similar in the long run).

It seems to me this solution would create a very strange-looking PS file.
In particular, any program trying to look for the text will find nothing.
And again, the fonts would have their hints and stuff.  Also, optimizing
the file with respect to a set of fonts would be impossible.  It's very
un-postscriptlike, and I don't like it.

I don't either. That's the only solution I found. However, I disagree about
your statement that we'd loose the hints (this is handled at the Pango
shaping stage already). And on high-resolution devices (300+ dpi), I don't
think it would make much difference (but IANATypographist)

However, remember that dia 0.90 doesn't really output "text" as
understandable by the average ASCII-aware perl script. 

(on a side note, GnomePrint does use private font names. I don't know
whether it beams the whole font or only the "useful" subset)

I think I can manage this last approach, borrowing a lot of cod^Wideas
from PAPS and after reading a lot of Postscript docs on how to save an
path and reuse it afterwards, scaled. This should also solve the problem
of "my printer doesn't like my font" (in an accidental way).

What happened to the idea of just dumping the font names and let ps2ps
handle any font insertion?

Because we have no idea what this font name is (the only solution I have
involves peeking into /var/lib/defoma's cache, but I can hear the loud yells
of the RPM, InstallShield and ports-based distributions)

        -- Cyrille

-- 
Grumpf.




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]