registry team mailing list archive

[Bug Watch Updater <164640@xxxxxxxxxxxxxxxxxx>]

Launchpad has imported 12 comments from the remote bug at
http://bugs.freedesktop.org/show_bug.cgi?id=13566.

If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.

------------------------------------------------------------------------
On 2007-12-08T02:30:59+00:00 Brandon Wright wrote:

David Turner has modified FreeType to be able to render sub-pixel
decimated glyphs using different methods of filtering. Fontconfig needs
new configurables to support selecting these new filtering options. A
patch follows that would correspond to one available for Cairo in bug
10301.

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/31

------------------------------------------------------------------------
On 2007-12-08T02:36:07+00:00 Brandon Wright wrote:

Created an attachment (id=12998)
Patch against fontconfig-2.5.0 adding options.

This patch adds a new option with 4 configuration constants. It is
modified from one available at
http://packages.ubuntu.com/gutsy/libs/libfontconfig1

Ubuntu developers originated this patch, albeit with the error of
creating name constants that conflicted with existing ones. This patch
modifies the original by prefixing the constant strings with
"lcdfilter".

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/32

------------------------------------------------------------------------
On 2007-12-20T07:19:46+00:00 Sebastien Bacher wrote:

the enumerations use lcdfilter and the define lcd_filter is that normal?

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/44

------------------------------------------------------------------------
On 2007-12-20T10:44:00+00:00 Brandon Wright wrote:

Created an attachment (id=13254)
Patch with correct define.

(In reply to comment #2)
> the enumerations use lcdfilter and the define lcd_filter is that normal?
> 
Nope, that was wrong. I've changed the patch.

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/45

------------------------------------------------------------------------
On 2008-01-13T07:59:59+00:00 Sylvain Pasche wrote:

I discussed this issue with Keith the other day:

17:48 < syp|> keithp: what do you think about https://bugs.freedesktop.org/show_bug.cgi?id=13566 ?
17:49 < keithp> syp|: fontconfig doesn't need these values, but cairo can add them itself if desired
17:50 < keithp> fontconfig allows applications to add their own variables to fontconfig
17:51 < keithp> you can do precisely the same operation from cairo code
17:51 < keithp> just add the values and constants using the existing public fontconfig API
17:51 < keithp> then fontconfig will happily parse those values appropriately
17:52 < syp|> keithp: is this way of doing already used for other configuration options?
17:53 < keithp> syp|: not in cairo, but I think Xft may use this
17:53 < keithp> yeah, FcNameRegisterConstants, FcNameRegisterObjectTypes
17:55 < syp|> ok thanks for the information. so this particular bug should be WONTFIXed?
17:57 < keithp> please see if you can make it work from cairo, then we can close the bug

So I tried to use the FcNameRegisterConstants and
FcNameRegisterObjectTypes functions to register the lcdfilter object
type and the lcdfilter* constants. However, I could see a time
dependency issue when doing this:

FcNameRegisterConstants() has to be called before the fontconfig
configuration file is read, otherwise the parser is not aware of the
defined constants and do not fill the pattern with them.

This can work when using the toy API and registering the constants from
_cairo_ft_scaled_font_create_toy(), because the fontconfig configuration
file is parsed later when FcDefaultSubstitute() is called (so it knows
about the constants at this time).

But it fails when using Pango, because it deals with FontConfig before
calling into the cairo API, so that the fontconfig configuration is
already parsed when we are in cairo-ft-font.c

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/53

------------------------------------------------------------------------
On 2008-01-13T10:42:48+00:00 Brandon Wright wrote:

I agree that this probably isn't the best place for these options. This
bug is here because the fontconfig patch was part of the original Ubuntu
patchset, and I was unaware it was possible to register configuration
objects from outside fontconfig itself.

Sylvain, the fontconfig configuration never really worked with the
Ubuntu patchset. In fact, the cairo patch currently only uses the
fontconfig options for name-to-constant mapping. This said, I'd say
there are two courses of action we can take from this standpoint:

1. Discard the fontconfig configuration of this value, use the freetype
constants, and load the configuration from the X resource database,
handling the string constants in cairo. This is the only method working
now anyway.

2. Figure out how to get the fontconfig object registration working even
with pango, moving all constants and configuration to cairo.

With either path, I really agree that, given the availability of that
config API, this patch would be unnecessary, and this bug can probably
be closed.

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/54

------------------------------------------------------------------------
On 2008-01-13T10:57:42+00:00 Sylvain Pasche wrote:

(In reply to comment #5)
> 1. Discard the fontconfig configuration of this value, use the freetype
> constants, and load the configuration from the X resource database, handling
> the string constants in cairo. This is the only method working now anyway.
> 
> 2. Figure out how to get the fontconfig object registration working even with
> pango, moving all constants and configuration to cairo.

I'll let Keith pronounce if this is feasible. Possibilities I see:
* reparse the configuration file after the constants have been registered (not sure fontconfig allows this, not so nice for performance).
* introduce a cairo_init() method that cairo consumers have to call before touching fontconfig (adds burden/incompatibility to cairo users).

Otherwise, there is a third possibility: Keep this parameter in
fontconfig and change cairo to take it into account, as this is done for
antialiasing, subpixel order or hinting.

I'm questioning having such an option at all, see
http://lists.cairographics.org/archives/cairo/2008-January/012685.html

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/55

------------------------------------------------------------------------
On 2008-01-13T11:46:13+00:00 Brandon Wright wrote:

(In reply to comment #6)
> I'll let Keith pronounce if this is feasible. Possibilities I see:
> * reparse the configuration file after the constants have been registered (not
> sure fontconfig allows this, not so nice for performance).
> * introduce a cairo_init() method that cairo consumers have to call before
> touching fontconfig (adds burden/incompatibility to cairo users).
> 
> Otherwise, there is a third possibility: Keep this parameter in fontconfig and
> change cairo to take it into account, as this is done for antialiasing,
> subpixel order or hinting.
> 
> I'm questioning having such an option at all, see
> http://lists.cairographics.org/archives/cairo/2008-January/012685.html

While I personally agree that the "Default" filter is adequate, we still need to have at least the "Legacy" filter available. The loss of this more-known, thinner filter would probably cause outrage among those who consider the new filters "too blurry." 
In that regard, I think that having "Default" as the default, but having only Xrdb configuration to set the other filters would be sufficient.

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/56

------------------------------------------------------------------------
On 2008-01-13T18:41:47+00:00 Freedesktop wrote:

As been already pointed out, registering in a library is not possible.
However if we are going to do it in cairo anyway, in a cairo namespace,
then we can forget about registering constants and types and just work
with strings.  That's whay pango does for pangogravity element for
example.

I still think this thing belongs into fontconfig because FreeType
exposes this configuration.  It's not a cairo-only thing.

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/57

------------------------------------------------------------------------
On 2008-01-13T19:50:35+00:00 Keith Packard wrote:

well, given that we can't make this work in any library, it seems like
the whole plan of building application-specific fontconfig constants is
a loss. Sigh.

I'll plan on adding this stuff for 2.6, please put together a patch that
includes the necessary documentation additions and I'll apply it.

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/58

------------------------------------------------------------------------
On 2008-01-14T13:50:23+00:00 Sylvain Pasche wrote:

Created an attachment (id=13713)
lcd filter type objects/constants and documentation update

As discussed on irc, I renamed the constants from lcdfilter* /
FC_LCD_FILTER_* to lcd* / FC_LCD_*.

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/59

------------------------------------------------------------------------
On 2008-05-03T19:34:03+00:00 Keith Packard wrote:

Applied in 53aec111074cf7b46d15eb84a55791d3c95bc15e

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/80


** Changed in: fontconfig
   Importance: Unknown => Wishlist

-- 
Build Firefox 3 against a subpixel-patched cairo
https://bugs.launchpad.net/bugs/164640
You received this bug notification because you are a member of Registry
Administrators, which is the registrant for Fontconfig.