Re: Familiy name in Alias and alias brokeness.



> CC> 3. - We are treating aliases inside the code as real fonts. There is
> CC> code that is using GP_FONT_ENTRY_ALIAS which we are no longer using when
> CC> loading the fontmap.
> 
> CC> [chema lamark libgnomeprint]$ grep  GP_FONT_ENTRY_ALIAS *.c
> CC> gnome-font-face.c:                      if (entry->type == GP_FONT_ENTRY_ALIAS)
> CC> gnome-font-face.c:      if (face->entry->type == GP_FONT_ENTRY_ALIAS) {
> CC> gnome-font-face.c:      if (face->entry->type == GP_FONT_ENTRY_ALIAS) {
> CC> gnome-font-face.c:      if (face->entry->type == GP_FONT_ENTRY_ALIAS) {
> 
> CC> I changed the code from using a entry type alias, to use a ->is_alias
> CC> flag. The reason for that is because I am preparing the move to pango
> CC> and having the fontmap know less about the fonts (like what format the
> CC> fonts are in) is going to be needed for the pango move. The way aliases
> CC> are being identified right now can be explained by:
> CC> http://bugzilla.gnome.org/showattachment.cgi?attach_id=13684
> 
> Well, is there any reason that gnome-print still needs to be
> having the fontmap file? I think the cost of getting these
> info dynamically is lower than the reading/writing/managing
> .fontmap file.

We no longer have a .fontmap file, we moved from using our own fontmap
to loading the fonts from fontconfig. I think we do need the fontmap, it
makes the implementation cleaner, we have to scan the fonts known to
fontconfig and filter out the ones we don't care about or know how to
handle. Also, we need to populate the font dialog so we have to load the
fontmap file then.

regards,
Chema





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]