(In reply to comment #47)
> This bug has all the information about the problem, there is nothing to add
> or explain more. Look for ulCodePageRange1 in the comments.
>
> That's very unfortunate that George resigned, and decided to revert the change
> instead of fixing the problem properly. Even if it's only marlett.ttf now,
> it's clear that fontforge incorrectly handles unicode ranges in the fonts,
> and even is not able to produce teh same consistent results when going a
> ttf -> sfd -> ttf route. That means that broken marlett.ttf fonts are going
> to cause us continuous headache.
Well headaches are bad, but brokeneness is worse.
Actually there is no solution to this, which can be used as default.
This makes the life of a package maintainer more worse
Hi,
(In reply to comment #47)
> This bug has all the information about the problem, there is nothing to add
> or explain more. Look for ulCodePageRange1 in the comments.
>
> That's very unfortunate that George resigned, and decided to revert the change
> instead of fixing the problem properly. Even if it's only marlett.ttf now,
> it's clear that fontforge incorrectly handles unicode ranges in the fonts,
> and even is not able to produce teh same consistent results when going a
> ttf -> sfd -> ttf route. That means that broken marlett.ttf fonts are going
> to cause us continuous headache.
Well headaches are bad, but brokeneness is worse.
Actually there is no solution to this, which can be used as default.
This makes the life of a package maintainer more worse