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)..
> > 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).
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.
Looks like adding a call to
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 know nothing of how FreeType will do non-ASCII glyphs, but from the list
> I gather it has no problem with it. So it's all in the encoding.
> I just now got the bounding boxes to do The Right Thing (apart from some
> cases where a glyph is larger than it's supposed to be), and got full Type1
> printing support. Pretty, pretty fonts, and in particular, fewer problems
> with differing lengths on screen and on paper (though the Courier font
> seems to have some issues with zooming).
> 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
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