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
> 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
> 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
> 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
> 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
for each face. You know better than I how to convert chars into Unicode.
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?