[Fonts]Core fonts issues [was: Problems with Type1 big fonts]
DD> Unless the old Type1 backend can unreservedly be replaced by the new DD> FreeType2 backend, then it should be disabled, and maybe even a "fake" DD> type1 font module created for the modular build so that existing DD> configurations don't break. If there are still reasons for wanting the DD> old backend, then it needs to be configurable, at least at build-time. DD> If we want to provide more flexibility in allowing the user to control DD> what font suffixes are handled by what backend, there would need to be DD> some type of run-time configurability. I was looking into that when other things came up; I may very well be able to come back to this. Anyway, here's the plan I had. The idea would be to have a new interface, Bool FontFileRegisterRendererPriority(FontRendererPtr, int priority) where the existing FontFileRegisterRenderer interface in renderer.c is an alias for FFRRP with priority set to 0. Priority is an integer (positive or negative), and renderers with higher priority override renderers of lower priority. The Type 1 renderer would register with negative priority for both PFA and CID; in the absence of another CID renderer, it would render CID fonts, but PFA fonts would be handled by FreeType. FreeType would register with default priority for both PFA and TTF. X-TT would register with positivie priority for TTF. In a configuration in which all renderers are linked in, X-TT would handle TTF, FreeType would handle PFA, and Type 1 would handle CID. In a default configuration (no X-TT), both PFA and TTF are handled by FreeType. The advantage of that is that there are no new configuration mechanisms -- we simply leverage off the existing module loader. It's also easily extensible -- I expect to implement bitmap support in the FreeType backend after 4.3.0, and then you'll want the existing bitmap renderers to override FreeType if they're linked in. The downside is that it's not completely flexible, not allowing for example to have TTF support using FreeType while using Type 1 for PFA. I don't think anyone cares. DD> Also, I'd really like to see some resolution to the separate "FreeType" DD> and "X-TT" backends for TrueType fonts. As it is now, if someone chooses DD> "X-TT", they will still need the old Type1 backend for Type1 fonts DD> regardless of other considerations. Is it still not possible to resolve DD> the issues that led to two TrueType backends in the first place? Here's my personal perception. X-TT contains support for embedded bitmaps, which FreeType 1 didn't have. The new FreeType backend fully supports embedded bitmaps. X-TT also contains a number of features such as fake bolding and automagic slanting, collectively known as TTCap. These should be handled at the toolkit level in my opinion, and at any rate implementing new features in the core fonts system at this point is pretty much pointless. Still, users of X-TT have become accustomed to these features being made available at the server level, and would probably not accept them being taken away. I shall not implement the said features in FreeType, which I want to remain a small and clean piece of code. I shall also not integrate myself the (existing) patches that implement TTCap in the FreeType backend. If there is a person interested in doing that, I'll be glad to help -- but only if said person commits to maintaining the code for the indefinite future. Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
[Fonts]Re: making editable charset/lang in fonts.conf
On Tue, 22 Oct 2002, Keith Packard wrote:
Thank you for your explanation.
> Around 12 o'clock on Oct 22, Jungshik Shin wrote:
>
> > 1. get a pattern from an application(fontconfig client)
> > 2. apply configuration-specified editing rules to the pattern.
> > For each font:
> > 3. read in font properties from fc-cache or (directly from font if
> > fc-cache is not present)
> > 4. measure the distance between the pattern and each font
>
> Fontconfig reads the font properties at startup time, and thereafter only
> when they change (it checks file mod times when fonts are listed).
I see. So, step 3 should be at the top.
> What we could do is add a set of rules executed when the patterns are
> loaded although I'm not sure that's precisely what you want,
More specifically, you meant 'the patterns holding font properties
are loaded from font-cache files', didn't you? If so, that's what I want.
FAMILY
.
where 'MODE' can be 'add'('append/prepend' just do), 'subtract' or
'assign' (or something similar to that effect). Because 'charset'
is already taken for Base85 representation of the coverage, a new
property (that has to be translated to charset internally) name
(e.g. coderange) might be used or 'charset' can be overloaded to mean
a more human-readable representation of the coverage in fonts.conf.
(sth. like [0x-0x]). For instance, I want the following to be
applied to font properties of 'Gulim Old Hangul Jamo' (a hack-encoded font
of which character/glyph assignment has NOTHING to do with actual Unicode
character assignment) read off from fc-cache BEFORE matching against
an application-provided pattern (by measuring the distance) begins.
Gulim Old Hangul Jamo
0x4e00-0x5400 // remove hack-encoding code points
0x1100-0x11ff // Hangul Jamos
0x302e-0x302f // Hangul Tone marks
0xac00-0xd7a4 // Hangul syllables
ko
Another example is for Baekmuk Batang which doesn't have glyphs
for U+1100-U+11FF, but can be used to render them nonetheless.
Baekmuk Batang
0x1100-0x11ff // Hangul Jamos
0x302e-0x302f // Hangul Tone marks
> it would significantly impact application startup performance.
Would just adding the feature to fontconfig have this significant
negative impact even in absence of editing rules for this feature in
fonts.conf? Or, would that negative impact manifest itself ONLY when
fonts.conf actually has editing rules for this feature? If the latter
is the case, the decision/choice would fall on end-users, wouldn't it?
If they think they can exchange a performance hit at application start-up
for a feature they desperately need, they would go for it. Otherwise,
they wouldn't put any editing rule to be applied at font-properties
loading stage.
> It seems like you want to select fonts based on Unicode coverage of the
> desired Hangul representation.
Actually, that's related but not exactly what I want. I may have get
you confused because last week I mentioned multiple ways of representing
Hangul along with what I'm talking about here. Or, am I
misunderstanding you?
I'd like to override 'charset' property(Unicode coverage) of some
fonts detected by fontconfig and stored in font-cache because the
detected value of 'charset' property doesn't represent their 'true' ability
due to hack-encodings used in them. In the example above, 'Old Gulim
Hangul Jamo' is detected to cover [U+4E00-U+52xx] and [U+-U+007F],
but I like that detected Unicode coverage to be modified by rules
specified in fonts.conf to reflect its 'true' ability ( [U+1100,U+11FF],
[U+AC00-U+D7A4], etc)
Arguably, this could be useful for more general cases than I made
it sound. Some fonts have precomposed Latin/Cyrillic/Greek letters
with diacritics, but they may not have combining diacritics themselves.
When a client of fontconfig like Pango tries to render a sequence of
a base character and a diacritic mark with such a font, Pango *seems*
to end up having two separate fonts, one for the base character(the font
specified in an application ) and the other for the diacritic mark even
though the first font (spec. in an application) has a glyph for the
precomposed charater made up of the base character and the diacritic
mark. Although this kind of problem can be solved at a level different
from fontcofing fontconfig could well help here.
> You could easily add a way to represent
> Unicode coverage in the config file; that would make adding coverage
> information possible with existing apps.
Yes, I need to do this (not just adding, but also subtracting) as
my example editing rules show. And, this 'editing' has to be done to
charset properties *before* the matching begins because for some fonts
(which would NOT be selected without this modification in charset
property), it's too late if it's done after the matching(font selection).
On the other hand, if I can edit charset property
of
[Fonts]Re: [Xpert]Core fonts issues [was: Problems with Type1 big fonts]
On Wed, Oct 23, 2002 at 08:13:10PM +0200, Juliusz Chroboczek wrote: >DD> Unless the old Type1 backend can unreservedly be replaced by the new >DD> FreeType2 backend, then it should be disabled, and maybe even a "fake" >DD> type1 font module created for the modular build so that existing >DD> configurations don't break. If there are still reasons for wanting the >DD> old backend, then it needs to be configurable, at least at build-time. > >DD> If we want to provide more flexibility in allowing the user to control >DD> what font suffixes are handled by what backend, there would need to be >DD> some type of run-time configurability. > >I was looking into that when other things came up; I may very well be >able to come back to this. Anyway, here's the plan I had. > >The idea would be to have a new interface, > > Bool FontFileRegisterRendererPriority(FontRendererPtr, int priority) > >where the existing FontFileRegisterRenderer interface in renderer.c is >an alias for FFRRP with priority set to 0. Priority is an integer >(positive or negative), and renderers with higher priority override >renderers of lower priority. > >The Type 1 renderer would register with negative priority for both PFA >and CID; in the absence of another CID renderer, it would render CID >fonts, but PFA fonts would be handled by FreeType. FreeType would >register with default priority for both PFA and TTF. X-TT would >register with positivie priority for TTF. > >In a configuration in which all renderers are linked in, X-TT would >handle TTF, FreeType would handle PFA, and Type 1 would handle CID. >In a default configuration (no X-TT), both PFA and TTF are handled by >FreeType. > >The advantage of that is that there are no new configuration >mechanisms -- we simply leverage off the existing module loader. It's >also easily extensible -- I expect to implement bitmap support in the >FreeType backend after 4.3.0, and then you'll want the existing bitmap >renderers to override FreeType if they're linked in. This would at least address the immediate issue, and it does need to be addressed before 4.3.0. >The downside is that it's not completely flexible, not allowing for >example to have TTF support using FreeType while using Type 1 for PFA. >I don't think anyone cares. If someone does, then I guess they'll implement the more flexible solution. If anyone is interested in that, please let me know. >DD> Also, I'd really like to see some resolution to the separate "FreeType" >DD> and "X-TT" backends for TrueType fonts. As it is now, if someone chooses >DD> "X-TT", they will still need the old Type1 backend for Type1 fonts >DD> regardless of other considerations. Is it still not possible to resolve >DD> the issues that led to two TrueType backends in the first place? > >Here's my personal perception. > >X-TT contains support for embedded bitmaps, which FreeType 1 didn't >have. The new FreeType backend fully supports embedded bitmaps. > >X-TT also contains a number of features such as fake bolding and >automagic slanting, collectively known as TTCap. These should be >handled at the toolkit level in my opinion, and at any rate >implementing new features in the core fonts system at this point is >pretty much pointless. Still, users of X-TT have become accustomed to >these features being made available at the server level, and would >probably not accept them being taken away. > >I shall not implement the said features in FreeType, which I want to >remain a small and clean piece of code. I shall also not integrate >myself the (existing) patches that implement TTCap in the FreeType >backend. > >If there is a person interested in doing that, I'll be glad to help -- >but only if said person commits to maintaining the code for the >indefinite future. The priority scheme should at least help a bit for now, but this issue still needs to be solved. There's always the drastic solution of just dropping one of them. Before anyone gets upset, that won't happen at least in the 4.3.0 timeframe, but I won't make any guarantees beyond that. At a minimum I'd like to see a clear summary of the issues from the point of view of an X-TT advocate. David ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
[Fonts]xft fonts not showing in font list
Hi all Before I start, allow me to thank and congratulate all those who have been involved in the xft project thus far. I recognise the time and effort that must have gone into it, and beleive it has major positive consequences in terms of bringing Linux to the desktop. Well done! And now for the woes I am using X 4.1 and have enabled the freetype and type1 modules. My XftConfig file has been set up to reflect the font paths, and xdpyinfo confirms that the RENDER extension is available on my system. If I run the command 'xterm -fa "lucida console" -fs 12' as a test command, it does in fact bring up a nicely anti-aliased desktop as expected. However, the problem is that although I am using KDE3, I cannot see any anti-aliased fonts in the font list. It only shows those in the FontPath entries in the XF86Config file. Any help is greatly appreciated. The annoying part is that I have managed to enable anti-aliased fonts on my machine at work using almost identical software (X 4.1, debian 3.0, KDE3 etc) Regards Richard ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
