Consider dropping gfxOS2Font and related classes

[dmik]

The gfxOS2Font and gfxOS2FontGroup classes use Freetype to implement glyph rendering on OS/2. However, there is already gfxFT2Font and friends (used on other platforms) that also use Freetype. Perhaps we can reuse these classes on OS/2 as well. Since these classes are upstream, they get instant updates and this way will not have to sync our specific OS/2 versions (which are pretty much outdated after updating to 17esr) with any future updates.

For examples of going out of sync see e.g. #21.

[dryeo]

Quite likely that these classes predate the introduction of Freetype and
Fontconfig

[dbanet]

Will this make @font-face work okay?

[dmik]

This really depends on how exactly @font-face is implemented in Firefox. I mean we will have to use Freetype for it anyway but we may (theoretically) get it "for free" provided that gfxFT2Font already supports it in a way we can use.

[dryeo]

On 06/02/14 09:24 AM, Dmitriy Kuminov wrote:

I mean we will have to use Freetype for it anyway but we may (theoretically) get it "for free" provided that gfxFT2Font already supports it in a way we can use.

Not sure but mzfntcfg may have to be extended to support locally
installed fonts.

[dryeo]

Another consideration is that we use Cairo and Freetype to get anti-aliased fonts whereas most systems do it system wide. Likely other similar stuff that we do on the application level instead of system level.

[dryeo]

Another consideration is that we use Cairo and Freetype to get anti-aliased fonts whereas most systems do it system wide. Likely other similar stuff that we do on the application level instead of system level.

[dmik]

Note that once this issue's task is done, 4f06eff needs to be reverted. See #74 for details.

[dmik]

The experiment of trying to switch from gfxOS2Fonts to gfxPangoFonts within #115 succeeded. We now have a build of Firefox 38 that doesn't crash and doesn't use gfxOS2Fonts. It has some problems with charsets still (see #115 (comment)) and I will address them in this ticket.

But first I will commit the gfxOS2Fonts to gfxPangoFonts switch that made FF 38 run (tomorrow, it needs some cleanup).

[dryeo]

So far the new fntcfg2 breaks warpsans to workplace sans mapping it seems. This is most visible in the menus which now seem to use Helvetia much like if workplace sans is unavailable. In particular Thunderbird, which I don't think I ever changed the fonts on, looks terrible with all the fonts being changed. SeaMonkey and Firefox aren't much better, especially the menus and tabs.
When the switch was made to Cairo, Peter put some work into maintaining the menus look, mostly by using Alex's workplace sans so that the Mozilla apps fit into the OS/2 look and feel.
Hmm, attempt to upload screenshots fails but if you compare screenshots side by side you'll see that not only do the menus look terrible but also the Google in the search bar and using issue #115 for comparison, the empty glyph boxes also look fuzzy compared to the original fntcfg. Glyph spacing is also different.
As recently as FF17 I built Firefox with the real fontconfig2.3.5 and didn't see any obvious differences compared to mzfntcfg

[dmik]

It no longer does. See http://trac.netlabs.org/ports/ticket/76 for details. But thanks for reporting.

[dmik]

The switch to pango is committed in 9b85e3b.

[dryeo]

On 11/26/15 09:13 AM, Dmitriy Kuminov wrote:

The switch to pango is committed in 9b85e3b
9b85e3b.

Will you be releasing your pango build? Here autoconf never produced a
working configure.

[dmik]

Sure, pango, cairo and pixman are to be released as RPMs. I have fixed all problems locally.

[dmik]

It seems that FcPatternGetCharSet (FC_CHARSET) always returns 0 for matched fonts (patterns) in our fontconfig. As a result, pango thinks the font doesn't have any chars and hence the boxes (even for ASCII). I have a feeling that our fontconfig doesn't properly extract charset information from font files (perhaps, because the respective parts are simply missing). Need to dig deeper in there.

[dmik]

It turns out that our fontconfig doesn't read charset information from fonts at all (because the whole font enumeration part is different). In particular, our code never calls FcFreeTypeQuery used in stock fontconfig to read out the charset information. If I dirty-hack Mozilla to think that every font has every char, it starts working as expected:

Now I tend to taking stock fontconfig sources as a whole and only change the small part where they enumerate fonts (and use the PM INI file instead of XML there, as in the current version), leaving all the remaining original logic intact. This will bring us charsets among other things.

Note that we don't get web fonts working out of the box though (see the github page on the screenshot). Maybe its support needs some actual charset information or there is some failure in the font download code. I will check that after I sort out the charset question.

[dmik]

Yes, using FcFreeTypeQuery manually (which in particular sets up the charset/language information) for each pattern returned from FcFontMatch solves the charset problem. So we should just switch to stock fontconfig to get charset selection and matching work correctly. Note also that we will get multiple propery value checks when we do that (mentioned here: #115 (comment)).

[dryeo]

Did you remember to re-enable the preference "gfx.downloadable_fonts.enabled".

[dmik]

Yes, doesn't help. There has to be something else.

[dmik]

Just for the record, we decided to move to the full upstream version of fontconfig instead of using the restricted one. The details are here: http://trac.netlabs.org/ports/ticket/77. And here is Firefox 38 running with new fontconfig (notice how nicely it selected a replacement for WarpSans):

It must be DjeaVu Sans or such (which I have installed). I will add a default substitution for WarpSans with Workplace Sans to the stock fonts.conf of course.

[dmik]

This issue may actually be closed; the main target is reached. The rest is to be done within #23 and in the respective fontconfig tickets (see above).