[Webkit-unassigned] [Bug 156148] [GTK] Since the SVG -> OTF Font Converter was enabled, some SVG layout tests are failing.

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Tue Apr 5 13:35:21 PDT 2016


https://bugs.webkit.org/show_bug.cgi?id=156148

--- Comment #13 from Carlos Alberto Lopez Perez <clopez at igalia.com> ---
(In reply to comment #12)
> 
> Given that the two converters are entirely different codebases, it's
> expected that the list of tables will be different.
> 
> When I look at the table lists, I see:
> - onlinefontconverter includes a "FontForge timestamp" table, which is
> unused by all text engines (that I'm aware of)
> - onlinefontconverter includes a 'GDEF' table. It doesn't appear that there
> is any information in that table which is also supplied in SVG, so I don't
> think I have any choice but to leave it out.
> - onlinefontconverter includes a 'GPOS' table, which is the table used by
> Windows (and maybe Harfbuzz/FreeType??) to perform kerning (instead of
> 'kern').
> - WebKit includes 'VORG' 'vhea' and 'vmtx' tables which are used for laying
> out vertical text (presumably onlinefontconverter doesn't care about
> vertical text?) (SVG fonts allow for vertical text).
> 
> 
> Looking at the ttx output, I see:
> - It doesn't like our timestamps. WebKit hardcodes these timestamps to 0
> because they are unused by all text engines (that I'm aware of).
> - It thinks our 'OS/2' table is too long. There are different versions of
> the 'OS/2' table. The TrueType spec only lists version 0, and mentions that
> Apple doesn't use this table. The OpenType spec lists versions 0, 1, 2, and
> 3. WebKit implements version 2, because that is what the Ahem.ttf in our
> LayoutTests/resources directory uses. The ttx tool probably doesn't
> understand version 2 of the table.
> 
> 
> Looking at your demo content on OS X, I see two things:
> - I think you made a typo in the section for "With WebKit converted svg->otf
> font:". My browser gives a 404 with the following URL:
> http://people.igalia.com/clopez/wkbug/156148/SVGFreeSans/SVGFreeSans.otg
> - The kerning appears to work on the other 3 sections (it seems most
> observable between the "T" and the "e" in "Team")
> 

Ups.

So the test and the screenshots were all buggy because it was trying to load a 404 (SVGFreeSans.otg) rather than SVGFreeSans.otf. I have fixed the html and created new screenshots.

> 
> However, your screenshots from your GTK system do show r197813 causing
> kerning to stop working.
> 

Yes, it seems.

> 
> So, after all that investigation, I have these thoughts:
> - It is definitely very reasonable for there to be a problem in the font
> converter. We are writing out fonts byte-per-byte, and the format is ugly
> enough / implementations are finicky enough that this is definitely possible
> (perhaps even probable?)
> - Because of the second sentence of the above item, the ttx tool isn't
> necessarily the best signal of problems. Every parser of these fonts will
> work differently, and I'm primarily interested in the browser's layout /
> rendering of text.
> - Therefore, instead of saying "there is something wrong" I think we need to
> focus on specific problems, and investigate them. It sounds like, in this
> situation, the specific problem is "kerning stopped working."

The previous broken test tricked me in thinking the generated OTF font was broken. Now after fixing the test, the screenshot with safari looks perfect.
So it seems at least Safari can read correctly the generated font.

> - All the investigation above is consistent with the known bug that the
> converter outputs 'kern' tables instead of 'GPOS' tables. This bug also
> caused kerning to stop working on Windows.
> - Making the converter write out GPOS tables instead of kern tables is not
> too difficult, I just haven't done it yet. I intend to do it in the
> near(-ish) future.
> 
> So, after all that, the question we need to ask ourselves is: Do we need to
> revert the patches until this bug is fixed?
> 

I don't think so.

I don't think is a major problem to have kerning broken with SVG fonts.
After all SVG fonts are not very used on web pages.


> I believe the answer to that question is "no" for the following reason:
> 
> You can consider the expressiveness of OpenType and SVG fonts like a Venn
> diagram. There are OpenType fonts which cannot be expressed in SVG, and
> there are SVG fonts which cannot be expressed in OpenType. Some examples of
> things which an SVG font can contain but an OpenType font can't are
> animations and (non-bitmapped) gradients. The reason why it is valuable to
> convert these fonts is that the payoff is worth the loss of expressiveness.
> The payoff is huge (huge performance increases, allowing for subpixel
> antialiasing, removing a whole class of security bugs) and the usage and
> impact of this lost expressiveness is low. Granted, kerning in SVG fonts is
> used a non-zero amount on the web, but the combination of 1. its low usage,
> 2. its low(-ish) visual impact, and 3. the fact that I intend to fix this
> bug soon make the case very clear.


Thanks for the comments.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20160405/5c130555/attachment-0001.html>


More information about the webkit-unassigned mailing list