Re: What's the prerenderer do?

[Lars Clausen <lrclause cs uiuc edu>]

On Sat, 2 Mar 2002, Cyrille Chepelov wrote:
> Le Sat, Mar 02, 2002, à 12:18:03PM -0600, Lars Clausen a écrit:
>
> > [If this mail looks funny, Gnus knows what it's talking about, and I
> > don't]
>
> hehe, indeed it does (look funny)..

It does?  In what way?  Gnus was warning me that there were more than two
sections, but I could see them, neither when sending nor when seeing the
mail on the list.

> > > Obviously some merging will be necessary.
> >
> > I thought it looked similar.  As I have an aversion to adding new
> > functions to the renderers, I instead added an extra mostly empty
> > renderops structure that can pick out the interesting stuff for the
> > prolog.  This has the advantage of allowing more than just strings to be
> > examined, for instance common colors could be predefined, or even common
> > images.  It might be slightly slower, though, which could be a problem
> > for the DPS renderer.
>
> Forget the DPS renderer. DPS on free *nix platforms is dead, even if
> XFree 4 has swallowed some DPS stuff. Since the GYVE project more or less
> died, nobody really uses it anymore. It was a nice experiment for me, but
> it's a patch I haven't touched or maintained in... uh, let's say fourteen
> months (no. It must be even more).

Are there any files left from the DPS renderer that should be removed?

> Now, on your code vs. the PrerenderString operation: it's probably very
> possible to refactor a little to get rid of PrerenderString, give all
> strings to the PS-Unicode during the "prolog pass" of your code, and
> fetch the encodings back from the PSU into the prolog (latter not
> actually needed, since encoding tables are defined just before their
> first use. That can sometimes make the rendering in Ghostscript a bit
> funny, but I don't think it adds a milisecond to the total rendering
> time).
>
> Actually, yes, one less operation would be nice, and your facility looks
> much more generic (and it actually overlaps PSU on only a very small
> part, the StringPrerenderer thing only). Anyway, the StringPrerenderer is
> nothing but a kludgy way of making the "header pass", in a strictly
> string-centric way. It could be possible to extend it for colours, line
> types or whatnot, but... your code is nicer.

Thank you!  It took me a while to convince myself that a prepass was ok,
but the pass itself doesn't take long.

> Looks like adding a call to 
>
>     psu_check_string_encodings(psu,utf8_text);
>
> in prolog_check_string()
>
> and you're set (PSU will still need all these callbacks, because we don't
> want to tell the PS Unicoder /how/ exactly we switch fonts and
> encodings).
>
> Then, once the encoding is checked, we can add a similar 
>
>     xxx_check_string_glyphs( xxx, utf8_text );
>
> just after psu_check_string_encodings, to use the facility we somewhat
> discussed with Akira and to which I think you're definitely an important
> party, and which would snarf each new glyph outline from FT and prepare
> it for inclusion in the prolog (you might want to pass also a pointer to
> the psu, so that this XXX facility could access the encoding tables, if
> necessary. I'm not sure it's necessary, all we need are the Postscript
> names, as returned by unicode_to_ps_name() already).

I'm horribly confused about the unicode things.  I'm leaving the prolog
stuff (mostly) alone now (except see below), so if you could fix these
things, my brain and I would be most thankful:)  I'm thinking the FreeType
version can be simple than the GDK version.

I haven't yet gotten even close to dumping single glyph outlines, I simply
dump the whole font.  I know it makes the file much larger, but it's a good
first approximation and *much* easier.  To reduce the size, I shall (soon)
have it use the standard PS fonts when possible.

> > Still need to look deeper into translating between the standard PS fonts
> > and FreeType fonts.  There are some hints that can be used, perhaps.
>
> Oh, one question: Has Geoff's patch been harmless, or better, a nice
> addition to your code ? It didn't break things on my machine (actually, I
> think it's better, that's why I included it, but I couldn't give it as
> much testing as I should have), but hey, I keep saying you're our
> resident FT expert...

Geoff's patch is harmless, as it only touches the GDK stuff.  I hope Geoff
will give FT a swing and see if he's getting the same problems there.

> On FT and glyphs and encoding: can you ask FT for any glyph outline,
> based on an Unicode character (32 bit value) ? If yes, my wild guess is
> that there won't be any major problems dealing with >127.). Looks like
> welding one or two details in addition to having the actual FT glyph
> outline to PS glyph stuff in place, hopefully. Akira, what's your opinion
> on this ?

Here's a bit from the freetype mailing list:

    > How do I find out a glyph index of characters>128 in TrueType Fonts
    > when the character is not ASCII but in Latin2 or CP1250 codepage ?

    The correct way is to activate a Unicode cmap (i.e. PID,EID=3,1), then
    convert the character code of your encoding to Unicode, and finally
    using FT_Get_Char_Index() to convert the Unicode encoded character into
    a glyph index.

This would happen in freetype_load_string() and freetype_render_string() in
lib/font.c.  We may well want to just use the Unicode cmap for all fonts
when Unicode is on, so in freetype_add_font(), add

    FT_Select_Charmap(face, ft_encoding_unicode);

for each face.  You know better than I how to convert chars into Unicode.

-Lars


-- 
Lars Clausen (http://shasta.cs.uiuc.edu/~lrclause)| Hårdgrim of Numenor
"I do not agree with a word that you say, but I   |----------------------------
will defend to the death your right to say it."   | Where are we going, and
    --Evelyn Beatrice Hall paraphrasing Voltaire  | what's with the handbasket?