[Bug 199331] Re: Changes in fontforge cause Wine's marlett.ttf to have incorrect available character sets
Bug Watch Updater
199331 at bugs.launchpad.net
Sat Feb 25 23:55:46 UTC 2012
Launchpad has imported 71 comments from the remote bug at
http://bugs.winehq.org/show_bug.cgi?id=10660.
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-04T00:35:27+00:00 Matheus Izvekov wrote:
Created attachment 9476
screenshot demonstrating the problem
All titlebar buttons are beeing drawn as an X, and they are all
misaligned too.
Reply at: https://bugs.launchpad.net/fontforge/+bug/199331/comments/0
------------------------------------------------------------------------
On 2007-12-04T01:57:12+00:00 Vitaliy-bugzilla wrote:
Looks like you don't have properly created marlett.ttf font. If you
compiled Wine yourself, check that you satisfied all the requirements.
Check with './configure --verbose'. If this is package - contact your
packager.
Reply at: https://bugs.launchpad.net/fontforge/+bug/199331/comments/1
------------------------------------------------------------------------
On 2007-12-04T02:06:07+00:00 Matheus Izvekov wrote:
Created attachment 9478
image representation of marlett.ttf
this was generated using fontimage /usr/share/wine/fonts/marlett.ttf
it looks ok, so it doesnt seem like a compilation/packaging problem
Reply at: https://bugs.launchpad.net/fontforge/+bug/199331/comments/2
------------------------------------------------------------------------
On 2008-01-30T19:40:02+00:00 S-wezel wrote:
i have discovered the same problem.
It seems to be a fontforge problem.
With version 20070831 the font file is created "correcly" (file size 6268 Bytes)
All newer versions generates a "wrong" font fiel (file size 6156 Bytes)
I have tested following versions of sourceforge:
20070831 <--- generates for wine a correct font file
20071210 <--- generates for wine a incorrect font file
20070915 <--- generates for wine a incorrect font file
20071002 <--- generates for wine a incorrect font file
20071110 <--- generates for wine a incorrect font file
20080109 (latest version) <--- generates for wine a incorrect font file
The question is, is it realy a problem with/in fontforge or with wine.
Reply at: https://bugs.launchpad.net/fontforge/+bug/199331/comments/3
------------------------------------------------------------------------
On 2008-01-30T19:52:13+00:00 James Hawkins wrote:
Invalid. If changing the version of fontforge is what fixes the bug,
then the bug is in fontforge. Please file a report with them.
Reply at: https://bugs.launchpad.net/fontforge/+bug/199331/comments/4
------------------------------------------------------------------------
On 2008-01-30T19:52:23+00:00 James Hawkins wrote:
Closing.
Reply at: https://bugs.launchpad.net/fontforge/+bug/199331/comments/5
------------------------------------------------------------------------
On 2008-01-31T05:22:47+00:00 Dmitry-baikal wrote:
This is really a fontforge bug. I'll mark this bug as a duplicate of
the bug 10952 with more information about its nature.
*** This bug has been marked as a duplicate of bug 10952 ***
Reply at: https://bugs.launchpad.net/fontforge/+bug/199331/comments/6
------------------------------------------------------------------------
On 2008-01-31T05:22:58+00:00 Dmitry-baikal wrote:
Closing.
Reply at: https://bugs.launchpad.net/fontforge/+bug/199331/comments/7
------------------------------------------------------------------------
On 2008-01-31T05:29:12+00:00 Dan Kegel wrote:
Thanks for the clear data, though. That looks like a
handy guide for others to avoid this problem.
Reply at: https://bugs.launchpad.net/fontforge/+bug/199331/comments/8
------------------------------------------------------------------------
On 2008-01-31T07:00:13+00:00 Dmitry-baikal wrote:
Unfortunately it looks like still nobody has filed a bug for fontforge about
this problem, at least google doesn't find anything not in the debian tracker.
Reply at: https://bugs.launchpad.net/fontforge/+bug/199331/comments/9
------------------------------------------------------------------------
On 2008-01-31T13:46:33+00:00 S-wezel wrote:
bug filled on the fontforge-devel-ml(also used for bug reporting) with subject:
"[BUG] incorrect generation of marlett.ttf font-file (used by wine) with newer fontforge versions"
Reply at: https://bugs.launchpad.net/fontforge/+bug/199331/comments/10
------------------------------------------------------------------------
On 2008-01-31T15:56:25+00:00 Dmitry-baikal wrote:
(In reply to comment #10)
> bug filled on the fontforge-devel-ml(also used for bug reporting) with subject:
> "[BUG] incorrect generation of marlett.ttf font-file (used by wine) with newer
> fontforge versions"
Thanks!
Reply at: https://bugs.launchpad.net/fontforge/+bug/199331/comments/11
------------------------------------------------------------------------
On 2008-02-06T00:28:36+00:00 S-wezel wrote:
here is the result of the bugreport on fontforge:
There is no bug in fontforge which reproduces the problem. But rather
the build-system part for generating the truetype font-files relies on a
behaviour of fontforge which has gone in newer version than 20070831.
So this is a bug in the wine build system.
In version 20070831 or older (i haven't tested older version then 20070831) it seems(i guess so) that fontforge can detect if the generated ttf font file should be a symbol font-file as the marlett font is. But in newer Version this detection (if there where a detection mechanism) is gone. The type of the generated font-file is determined by the file extension.
In case for the marlett symbol ttf font the right extension is .sym.ttf.
I have generated a patch(wine-fontforge-symbol-font.patch) which
modifies the Makefile.in so that for the marlett.ttf file following
commands are invoked:
fontforge -script ../fonts/genttf.ff marlett.sfd marlett.sym.ttf
mv marlett.sym.ttf marlett.ttf
Reply at: https://bugs.launchpad.net/fontforge/+bug/199331/comments/12
------------------------------------------------------------------------
On 2008-02-06T00:32:18+00:00 S-wezel wrote:
Created attachment 10629
patch for generating correct marlett.ttf font file with newer fontforge version
than 20070831
Reply at: https://bugs.launchpad.net/fontforge/+bug/199331/comments/13
------------------------------------------------------------------------
On 2008-02-06T01:04:24+00:00 Dan Kegel wrote:
Sounds like it needs reopening, then.
Reply at: https://bugs.launchpad.net/fontforge/+bug/199331/comments/14
------------------------------------------------------------------------
On 2008-02-06T04:24:21+00:00 Dmitry-baikal wrote:
marlett.sfd already has the necessary information - Encoding: Symbol, there is
nothing do detect.
Reply at: https://bugs.launchpad.net/fontforge/+bug/199331/comments/15
------------------------------------------------------------------------
On 2008-02-06T04:39:25+00:00 Matheus Izvekov wrote:
(In reply to comment #15)
> marlett.sfd already has the necessary information - Encoding: Symbol, there is
> nothing do detect.
>
>From what I understand, they dont honor this token "Encoding" anymore.
Reply at: https://bugs.launchpad.net/fontforge/+bug/199331/comments/16
------------------------------------------------------------------------
On 2008-02-06T04:45:45+00:00 Dmitry-baikal wrote:
(In reply to comment #16)
> (In reply to comment #15)
> > marlett.sfd already has the necessary information - Encoding: Symbol, there is
> > nothing do detect.
> >
> From what I understand, they dont honor this token "Encoding" anymore.
Right, and that's where the source of this bug is.
Reply at: https://bugs.launchpad.net/fontforge/+bug/199331/comments/17
------------------------------------------------------------------------
On 2008-02-06T06:59:07+00:00 S-wezel wrote:
ok i will report this on the fontforge-devel ml
Reply at: https://bugs.launchpad.net/fontforge/+bug/199331/comments/18
------------------------------------------------------------------------
On 2008-02-06T08:29:45+00:00 Dmitry-baikal wrote:
http://sourceforge.net/mailarchive/forum.php?thread_name=200801311442.39548.s.wezel%40web.de&forum_name
=fontforge-devel
George Williams writes:
> The other change is that in the old days if a font was displayed in
> "Symbol" encoding, then FontForge would save it with a 3,0 (symbol) cmap
> entry. That was a misunderstanding on my part. I assumed a "Symbol"
> encoding in Adobe's sense was the same as MicroSoft's, and that was
> wrong. So in modern FontForges the font is saved with a 3,1 (unicode)
> encoding instead. If you really want a symbol (3,0) cmap vector, use
> Generate($2, "sym.ttf", 0);
> instead.
TT_PLATFORM_MICROSOFT = 3
TT_MS_ID_SYMBOL_CS = 0
TT_MS_ID_UNICODE_CS = 1
So by (3,1) George means that modern Fontforge versions create a Unicode
charmap for marlett.ttf. But that's not the problem, the problem is that
Fontforge now sets Latin1 bit in the ulCodePageRange1 fileld in the OS2
TrueType header.
Reply at: https://bugs.launchpad.net/fontforge/+bug/199331/comments/19
------------------------------------------------------------------------
On 2008-02-08T03:31:37+00:00 S-wezel wrote:
here is the last response of my question from George Williams:
George Williams wrote:
> Stephan Wezel wrote:
> > Currently they still thinking it isn't a wine bug but an bug in
> > fontforge. But when you say that the old behaviour on which the wine
> > build system currently relies was wrong then i will report it on the
> > mentioned wine bugreport.
>
> That is correct.
>
> I had assumed that adobe's symbol encoding (which is what "symbol" means
> inside fontforge) was the same as Microsoft's 3,0 cmap entry. It is not.
> I presume that they made the same mistake, aided in doing so by my
> mistake.
>
> In my opinion, marlett.sfd is erroneous. It claims an adobe symbol
> encoding, which it does not, in fact, have. I don't think that could be
> created with fontforge, I think someone must have hand edited the file
> to produce that peculiar melange.
So it seems really a bug in the wine build-system part which generates the font.
Because it relays on a behavior of fontforge which was incorrect.
Reply at: https://bugs.launchpad.net/fontforge/+bug/199331/comments/20
------------------------------------------------------------------------
On 2008-02-08T05:03:30+00:00 Dmitry-baikal wrote:
That still doesn't answer the question why fontforge now sets Latin1 *and*
Symbol bits in the ulCodePageRange1 fileld in the OS2 TrueType header, while
previously it only set the Symbol one.
At the very least there should be a way to tell fontforge what code page
bits should be set in the ulCodePageRange1 fileld, and relying on the file
extension looks wrong to me.
Also, there is a thing called backwards compatibility. A behaviour of
fontforge that was valid for years now suddenly called broken, making
previously valid .sfd files useless.
Reply at: https://bugs.launchpad.net/fontforge/+bug/199331/comments/21
------------------------------------------------------------------------
On 2008-02-08T11:48:40+00:00 S-wezel wrote:
then write directly to George Williams, because i'm not firm enough with
fontforge and generating fonts.
Reply at: https://bugs.launchpad.net/fontforge/+bug/199331/comments/22
------------------------------------------------------------------------
On 2008-02-08T12:00:05+00:00 Dmitry-baikal wrote:
(In reply to comment #22)
> then write directly to George Williams, because i'm not firm enough with
> fontforge and generating fonts.
Can you please point him to this bug, and ask to comment here? That way
everybody can participate in the discussion of the problem, and that will
be tracked for future reference.
Reply at: https://bugs.launchpad.net/fontforge/+bug/199331/comments/23
------------------------------------------------------------------------
On 2008-02-08T12:11:18+00:00 S-wezel wrote:
(In reply to comment #23)
> (In reply to comment #22)
> > then write directly to George Williams, because i'm not firm enough with
> > fontforge and generating fonts.
>
> Can you please point him to this bug, and ask to comment here? That way
> everybody can participate in the discussion of the problem, and that will
> be tracked for future reference.
>
I have several times mentioned this bug in my mails. But it is curious why all furthermore mails aren't in the sourceforge fontforgedevel ml archiv.
He is also a bit tired about this topic, due my bad knowledge about this
topic. And how i had tried to explain your concerns why it seems to be
fontforge bug.
I will try it but i hope he doesn't gent angry about me.
Reply at: https://bugs.launchpad.net/fontforge/+bug/199331/comments/24
------------------------------------------------------------------------
On 2008-02-08T23:08:32+00:00 Gww-u wrote:
I have explained this three times on the fontforge mailing list.
"I have answered three questions, and that is enough,"
Said his father. "Don't give yourself airs!
Do you think I can listen all day to such stuff?
Be off, or I'll kick you down stairs.
The problem is that marlett.sfd was taking advantage of a bug in
fontforge. That bug has now been fixed. marlett.sfd is rather
problematic itself as it claims an adobe symbol encoding when it does
not, in fact, have one. I hope someone hand-edited the sfd file, because
if not there is another bug in fontforge.
At one point I assumed that MicroSoft's 3,0 cmap entry was the same as
Adobe's symbol encoding (To fontforge a "symbol" encoding is Adobe's).
It is not. In fact MicroSoft's 3,0 cmap entry is not a true encoding as
there is no charset associated with it. At any rate FontForge no longer
generates a 3,0 cmap entry for something with Adobe's Symbol encoding.
As Stephan says I am extremely tired of repeating this same point over
and over. A dieu.
Reply at: https://bugs.launchpad.net/fontforge/+bug/199331/comments/25
------------------------------------------------------------------------
On 2008-02-09T02:22:14+00:00 Dmitry-baikal wrote:
George, I understand your frustration on this, it must be mostly caused by
a miscommunication. Could you please answer the questions in the comments
#19 and #21?
Reply at: https://bugs.launchpad.net/fontforge/+bug/199331/comments/26
------------------------------------------------------------------------
On 2008-02-09T02:41:13+00:00 Dmitry-baikal wrote:
*** Bug 10952 has been marked as a duplicate of this bug. ***
Reply at: https://bugs.launchpad.net/fontforge/+bug/199331/comments/27
------------------------------------------------------------------------
On 2008-02-11T08:44:38+00:00 Dmitry-baikal wrote:
*** Bug 11538 has been marked as a duplicate of this bug. ***
Reply at: https://bugs.launchpad.net/fontforge/+bug/199331/comments/28
------------------------------------------------------------------------
On 2008-02-11T12:06:03+00:00 Dmitry-baikal wrote:
I just performed a simple test: took marlett.ttf from XP (it has only symbol
bit set in ulCodePageRange1 (0x80000000)), opened it with Fontforge and saved
as marlett.sfd. Then I generated marlett.ttf from marlett.sfd using genttf.ff
from wine/fonts (Open($1; Generate($2, "ttf", 0);)
New marlett.ttf has ulCodePageRange1 set to 0x80000001, i.e. both symbol and
latin1 unicode ranges. Does that qualify as a fontforge bug?
Reply at: https://bugs.launchpad.net/fontforge/+bug/199331/comments/29
------------------------------------------------------------------------
On 2008-02-12T00:06:54+00:00 Gww-u wrote:
If the latin1 bit is not set on a normal font then windows won't use it
for anything useful. So FontForge pretty much always sets this bit when
outputting normal fonts. When outputting symbol fonts it does not set
this bit as it isn't applicable.
The root of the problem, as I keep saying (five times? six?), is that
fontforge no longer generates a 3,0 cmap entry for marlett.sfd (unless
you specifically request a symbol encoding). This has a number of
implications, including the way the OS/2 code pages are defaulted.
If you don't want fontforge to default the setting of the code
pages/unicode ranges then you can set them explicitly in Element->Font
Info->OS/2->Charsets.
No this doesn't count as a fontforge bug. If you believe you have a
fontforge bug please report them on the fontforge mailing list. The wine
bug-tracker is not an appropriate place.
>That still doesn't answer the question why fontforge now sets Latin1 *and*
>Symbol bits in the ulCodePageRange1 fileld in the OS2 TrueType header, while
>previously it only set the Symbol one.
When I use fontforge to generate a truetype font with a symbol encoding it does *NOT* set the latin1 bit.
Open("marlett.sfd")
Generate("marlett.sym.ttf")
>Also, there is a thing called backwards compatibility. A behaviour of
>fontforge that was valid for years now suddenly called broken, making
>previously valid .sfd files useless.
As I pointed out in my previous post marlett is not a valid sfd file. It claims an encoding (adobe symbol) which it does not have.
There seems to be an assumption that FontForge's symbol encoding (which is Adobe's) means the same as the symbol cmap type. That is not the case.
The behavior you are depending on was never documented.
Now can we please leave this topic?
The old behavior was wrong. Marlett.sfd is mildly wrong. You have a fix which works.
Reply at: https://bugs.launchpad.net/fontforge/+bug/199331/comments/30
------------------------------------------------------------------------
On 2008-02-12T00:30:35+00:00 WanderingVillager wrote:
As I recall, I once tried to override things in "Element->Font
Info->OS/2->Charsets" as an experiment, but without success. It set the
latin1 bit regardless. (In any case, even if that had worked, I guess
the sfd file must be patched.)
Reply at: https://bugs.launchpad.net/fontforge/+bug/199331/comments/31
------------------------------------------------------------------------
On 2008-02-12T02:59:49+00:00 Dmitry-baikal wrote:
(In reply to comment #30)
> If the latin1 bit is not set on a normal font then windows won't use it for
> anything useful.
This is not true. There are other useful unicode ranges in the fonts
besides Latin1.
> So FontForge pretty much always sets this bit when outputting
> normal fonts. When outputting symbol fonts it does not set this bit as it isn't
> applicable.
What if the font developer creates a font with several unicode ranges,
including symbol?
> The root of the problem, as I keep saying (five times? six?), is that fontforge
> no longer generates a 3,0 cmap entry for marlett.sfd (unless you specifically
> request a symbol encoding). This has a number of implications, including the
> way the OS/2 code pages are defaulted.
Font character mappings and unicode ranges are different things, not related
to each other. It's perfectly legal to have a unicode character map, and
simultaneously have a symbol unicode range in the font.
> If you don't want fontforge to default the setting of the code pages/unicode
> ranges then you can set them explicitly in Element->Font Info->OS/2->Charsets.
As Ove mentioned, that doesn't work for some reason.
> No this doesn't count as a fontforge bug. If you believe you have a fontforge
> bug please report them on the fontforge mailing list. The wine bug-tracker is
> not an appropriate place.
This bug a special. I has been closed as invalid, but reopened later to better
understand the problem.
> >That still doesn't answer the question why fontforge now sets Latin1 *and*
> >Symbol bits in the ulCodePageRange1 fileld in the OS2 TrueType header, while
> >previously it only set the Symbol one.
> When I use fontforge to generate a truetype font with a symbol encoding it does
> *NOT* set the latin1 bit.
> Open("marlett.sfd")
> Generate("marlett.sym.ttf")
My impression is that the font is being created based on the information in
the font file. If there is a need in a hack to specify font encoding using
file extension (what if a developer needs several of them in the single font?)
then this looks like a limitation of the file format, and should be considered
to be fixed.
Again I'd like to point out that .ttf -> .sfd -> .ttf path leads to creation
of a not compatible font to an original one, regardless which unicode ranges
the font contains.
> >Also, there is a thing called backwards compatibility. A behaviour of
> >fontforge that was valid for years now suddenly called broken, making
> >previously valid .sfd files useless.
> As I pointed out in my previous post marlett is not a valid sfd file. It claims
> an encoding (adobe symbol) which it does not have.
> There seems to be an assumption that FontForge's symbol encoding (which is
> Adobe's) means the same as the symbol cmap type. That is not the case.
> The behavior you are depending on was never documented.
> Now can we please leave this topic?
> The old behavior was wrong. Marlett.sfd is mildly wrong. You have a fix which
> works.
I'm sorry, but I don't think that a hack with a file extension qualifies as
a fix. I'd prefer to have a real solution which doesn't prevent adding other
unicode ranges to marlett in future.
Reply at: https://bugs.launchpad.net/fontforge/+bug/199331/comments/32
------------------------------------------------------------------------
On 2008-02-12T04:34:01+00:00 Gww-u wrote:
> As Ove mentioned, that doesn't work for some reason.
You are right. There's now a patch in fontforge which makes it work.
>I'm sorry, but I don't think that a hack with a file extension qualifies as
>a fix. I'd prefer to have a real solution which doesn't prevent adding other
>unicode ranges to marlett in future.
Well, the approach you are using was never supposed to work. The fact that it did was a bug.
Reply at: https://bugs.launchpad.net/fontforge/+bug/199331/comments/33
------------------------------------------------------------------------
On 2008-02-12T06:00:05+00:00 Dmitry-baikal wrote:
(In reply to comment #33)
> > As Ove mentioned, that doesn't work for some reason.
> You are right. There's now a patch in fontforge which makes it work.
Thanks, once it's in a released version of fontforge I'll try to use it.
> >I'm sorry, but I don't think that a hack with a file extension qualifies as
> >a fix. I'd prefer to have a real solution which doesn't prevent adding other
> >unicode ranges to marlett in future.
> Well, the approach you are using was never supposed to work. The fact that it
> did was a bug.
George, for unknown to me reason, you are avoiding the questions, and one of
them is how to create a .ttf from .sfd *without* using a file extension hack,
i.e. is there a way to specify unicode ranges of the font in an .sfd file?
Reply at: https://bugs.launchpad.net/fontforge/+bug/199331/comments/34
------------------------------------------------------------------------
On 2008-02-13T01:18:15+00:00 Gww-u wrote:
:-) I am avoiding the question because I am so tired of this argument I
am not reading them. I give up. It is easier for me to reinstate the
original behavor than to keep arguing. I am sorry for any problems I
have caused.
Reply at: https://bugs.launchpad.net/fontforge/+bug/199331/comments/35
------------------------------------------------------------------------
On 2008-02-13T07:51:42+00:00 Dmitry-baikal wrote:
(In reply to comment #35)
> :-) I am avoiding the question because I am so tired of this argument I am not
> reading them. I give up. It is easier for me to reinstate the original behavor
> than to keep arguing. I am sorry for any problems I have caused.
Now I'm confused. Am I right that instead of understanding the problem and
fixing it properly you prefer to restore previous, admittedly broken behaviour?
Reply at: https://bugs.launchpad.net/fontforge/+bug/199331/comments/36
------------------------------------------------------------------------
On 2008-02-13T13:29:46+00:00 Dan Kegel wrote:
I think so, but only because the interaction with the wine
developers has been so dysfunctional. I've been watching,
and the conversation hasn't been exactly pleasant. Can't
say I blame him.
There might be bugs on both sides, and a calm investigation
by somebody who had enough time to look at both sides himself
would probably get to the bottom of it pretty quickly.
Reply at: https://bugs.launchpad.net/fontforge/+bug/199331/comments/37
------------------------------------------------------------------------
On 2008-02-13T14:41:15+00:00 Dmitry-baikal wrote:
I believe that I did everything I could do from Wine point of view:
I described what and where the problem is. Now it's just up to fontforge
developer(s) to make .sfd -> .ttf (and probably .ttf -> .sfd) font generation
work properly without any external hacks like proposed file extensions, since
that apparently doesn't allow to create fonts with Symbol and some other
unicode range bits set in ulCodePageRange1.
If "Encoding: Symbol" is really wrong in marlett.sfd, let's remove it, but
we need a working solution/replacement which works, and preferably works
with old, current and new fontforge versions.
Reply at: https://bugs.launchpad.net/fontforge/+bug/199331/comments/38
------------------------------------------------------------------------
On 2008-02-23T15:03:01+00:00 Dmitry-baikal wrote:
(For some reason George got removed from the cc: list, re-adding since he is
a key person for this bug)
George, is there anything we can do to help better understanding and fixing
this bug?
Reply at: https://bugs.launchpad.net/fontforge/+bug/199331/comments/39
------------------------------------------------------------------------
On 2008-02-24T22:02:20+00:00 Benjo316-w wrote:
I found a TGMarlett.sfd somewhere on the web and opened it in fontforge,
then generated the font as "TrueType (Symbol)" and it's working
correctly in Wine.
Is that what you guys were trying to do, or is there a different way
that you wanted to do it?
Reply at: https://bugs.launchpad.net/fontforge/+bug/199331/comments/40
------------------------------------------------------------------------
On 2008-02-25T03:53:09+00:00 Dmitry-baikal wrote:
(In reply to comment #40)
> I found a TGMarlett.sfd somewhere on the web and opened it in fontforge, then
> generated the font as "TrueType (Symbol)" and it's working correctly in Wine.
> Is that what you guys were trying to do, or is there a different way that you
> wanted to do it?
You have omitted all the details. What version of fontforge are you using? Does
the script that Wine is using to generate marlett.ttf work for you?
Reply at: https://bugs.launchpad.net/fontforge/+bug/199331/comments/41
------------------------------------------------------------------------
On 2008-02-25T11:54:46+00:00 Benjo316-w wrote:
(In reply to comment #41)
> (In reply to comment #40)
> > I found a TGMarlett.sfd somewhere on the web and opened it in fontforge, then
> > generated the font as "TrueType (Symbol)" and it's working correctly in Wine.
> > Is that what you guys were trying to do, or is there a different way that you
> > wanted to do it?
>
> You have omitted all the details. What version of fontforge are you using? Does
> the script that Wine is using to generate marlett.ttf work for you?
>
I apologize; I forgot.
Fontforge version: 0.0.20071110-1build2 from the Ubuntu Hardy repository.
I don't know where the script is located though, could you tell me so I could test?
Reply at: https://bugs.launchpad.net/fontforge/+bug/199331/comments/42
------------------------------------------------------------------------
On 2008-02-25T12:13:36+00:00 Dmitry-baikal wrote:
(In reply to comment #42)
> Fontforge version: 0.0.20071110-1build2 from the Ubuntu Hardy repository.
> I don't know where the script is located though, could you tell me so I could
> test?
Obviously the script is in the Wine source repository. Have you read all the
comments in the bug? I'm sorry, but if you don't understand the problem(s)
behind this bug most likely there is no need to test/report anything.
Reply at: https://bugs.launchpad.net/fontforge/+bug/199331/comments/43
------------------------------------------------------------------------
On 2008-02-25T15:44:07+00:00 Gww-u wrote:
I removed myself from the bug. I have done so again.
I have reverted the change you complained about. I don't see that there
is anything more I can do for you. Please stop bothering me.
Reply at: https://bugs.launchpad.net/fontforge/+bug/199331/comments/44
------------------------------------------------------------------------
On 2008-02-25T21:10:11+00:00 Benjo316-w wrote:
(In reply to comment #43)
> Obviously the script is in the Wine source repository. Have you read all the
> comments in the bug? I'm sorry, but if you don't understand the problem(s)
> behind this bug most likely there is no need to test/report anything.
>
Yes, at least twice; Obviously I missed something though.
I'm sure if there was a clear description of how to test and reproduce the
bug I wouldn't have any problems testing and possibly actually helping in
this bug. As far as I could see, there was no method, nor a way to find
the method, of testing this.
At any rate, I can see I'm unwanted here, so I'm removing myself from
the CC list. Dealing with Windows is easier than dealing with some of
the Wine developers(Though, I'm not going back to Windows).
Have a nice day, and bye.
Reply at: https://bugs.launchpad.net/fontforge/+bug/199331/comments/45
------------------------------------------------------------------------
On 2008-02-25T21:19:42+00:00 Dan Kegel wrote:
That's two people we've driven away. This bug is cursed!
Reply at: https://bugs.launchpad.net/fontforge/+bug/199331/comments/46
------------------------------------------------------------------------
On 2008-02-26T01:10:51+00:00 Dmitry-baikal wrote:
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.
Reply at: https://bugs.launchpad.net/fontforge/+bug/199331/comments/47
------------------------------------------------------------------------
On 2008-03-06T06:04:57+00:00 Stephan Adig wrote:
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
Reply at: https://bugs.launchpad.net/fontforge/+bug/199331/comments/48
------------------------------------------------------------------------
On 2008-03-06T06:22:41+00:00 Dmitry-baikal wrote:
(In reply to comment #48)
> 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
Wine depends on fontforge, and we have any control on this (it even looks
much worse taking into account George's stance in the comments above).
To me it's clear that it's the fontforge bug, why this bug stays open
is beyond my understanding. I'd suggest to keep reporting this to George,
if enough people starts doing that perhaps there is a chance it will be
fixed properly.
Reply at: https://bugs.launchpad.net/fontforge/+bug/199331/comments/49
------------------------------------------------------------------------
On 2008-03-06T06:23:25+00:00 Dmitry-baikal wrote:
s/we have any control on this/we have no any control on this/
Reply at: https://bugs.launchpad.net/fontforge/+bug/199331/comments/50
------------------------------------------------------------------------
On 2008-03-06T07:29:53+00:00 Dan Kegel wrote:
Continuing to report it to George in the same way
will just annoy him.
We need somebody to hand him a regression test case
and probably a fix.
Reply at: https://bugs.launchpad.net/fontforge/+bug/199331/comments/51
------------------------------------------------------------------------
On 2008-03-06T07:54:35+00:00 Dmitry-baikal wrote:
(In reply to comment #51)
> Continuing to report it to George in the same way
> will just annoy him.
> We need somebody to hand him a regression test case
> and probably a fix.
That's not a regression, that's how fontforge handles unicode ranges of
the font in general.
Reply at: https://bugs.launchpad.net/fontforge/+bug/199331/comments/52
------------------------------------------------------------------------
On 2008-03-06T07:58:19+00:00 Dan Kegel wrote:
Whatever. If we want them to change something,
we have to give them a good test case and a fix.
Reply at: https://bugs.launchpad.net/fontforge/+bug/199331/comments/53
------------------------------------------------------------------------
On 2008-03-06T08:07:35+00:00 Dmitry-baikal wrote:
(In reply to comment #53)
> Whatever. If we want them to change something,
> we have to give them a good test case
They have it already, and I mentioned it several times in this bug: open
marlett.ttf from windows, save it to marlett.sfd, then open marlett.sfd and
save it to marlett.ttf. George insists that the .sym extension has to be
used, but that's not acceptable as I explained above.
> and a fix.
That requires an intimate knowledge of fontforge, and needs to be fixed by
a fontforge developer.
Reply at: https://bugs.launchpad.net/fontforge/+bug/199331/comments/54
------------------------------------------------------------------------
On 2008-03-06T08:10:21+00:00 Dan Kegel wrote:
> I mentioned it several times in this bug
Not in a way that doesn't annoy them. An automated
test would be better.
We've pissed them off; now we either have to charm them
by giving them a very, very nice test case, and/or
fix it ourselves, and/or somehow otherwise get
back on their good side. Continued whining about
how they aren't fixing the bug for us won't cut it.
Reply at: https://bugs.launchpad.net/fontforge/+bug/199331/comments/55
------------------------------------------------------------------------
On 2008-03-06T09:09:54+00:00 Dmitry-baikal wrote:
(In reply to comment #55)
> > I mentioned it several times in this bug
> Not in a way that doesn't annoy them. An automated
> test would be better.
It looks like 'Generate' keyword in fontforge scripting language doesn't
support creation of .sfd (fontforge own file format) files, otherwise
something like the following script would qualify as an automated test
I'd guess (and yes, the fact that Wine already has/uses a similar script
has already been pointed out):
Open("marlett.ttf");
Generate("marlett.sfd");
Open("marlett.sfd");
Generate("marlett2.ttf");
which still requires an inspection of the unicode ranges field in the OS/2
header of the generated marlett2.ttf.
> We've pissed them off; now we either have to charm them
> by giving them a very, very nice test case, and/or
> fix it ourselves, and/or somehow otherwise get
> back on their good side. Continued whining about
> how they aren't fixing the bug for us won't cut it.
If we would be pissed off by every report pointing out bugs in Wine how far
Wine would be these days?
Reply at: https://bugs.launchpad.net/fontforge/+bug/199331/comments/56
------------------------------------------------------------------------
On 2008-03-06T13:37:02+00:00 WanderingVillager wrote:
>From what I figured from what he said, George applied a fix to the
unicode ranges so they can be overridden from the .sfd file, but
reverted the change that required the .sym extension. If so, Wine would
be fine, just need to add those overrides to the .sfd. Maybe someone
could check out the current fontforge cvs and see if it works like that
now...
Reply at: https://bugs.launchpad.net/fontforge/+bug/199331/comments/57
------------------------------------------------------------------------
On 2008-03-06T17:12:16+00:00 WanderingVillager wrote:
As for creating a test case, to save the imported ttf to a sfd file, use
Save(), not Generate().
Reply at: https://bugs.launchpad.net/fontforge/+bug/199331/comments/58
------------------------------------------------------------------------
On 2008-03-06T17:50:07+00:00 Dan Kegel wrote:
> If we would be pissed off by every report pointing out
> bugs in Wine how far Wine would be these days?
Just because we have tough hides doesn't mean
we can assume everybody else does.
I'm just recognizing how George feels, and
proposing a way we can get what we want.
It may be a bit more work for us than you feel
is right, but that's life.
Reply at: https://bugs.launchpad.net/fontforge/+bug/199331/comments/59
------------------------------------------------------------------------
On 2008-03-07T04:34:03+00:00 Scott Ritchie wrote:
>From a practical standpoint, Ubuntu Hardy is coming out soon, and while
Wine can be patched at any time before release I believe the version of
fontforge might be set. We may want to have a workaround anyway.
Then again, Ubuntu is not opposed to patching fontforge if the changes
we get are minimal enough.
See Launchpad bug: https://bugs.launchpad.net/bugs/199331
So, as a package maintainer, what should I do? Someone needs to point me to a patch for Wine or a patch for fontforge that I can ask to be merged in.
Reply at: https://bugs.launchpad.net/fontforge/+bug/199331/comments/61
------------------------------------------------------------------------
On 2008-03-07T04:47:57+00:00 Dmitry-baikal wrote:
(In reply to comment #60)
> So, as a package maintainer, what should I do? Someone needs to point me to a
> patch for Wine or a patch for fontforge that I can ask to be merged in.
As a package maintainer you could use an older fontforge version known to
produce correct Wine fonts.
Reply at: https://bugs.launchpad.net/fontforge/+bug/199331/comments/62
------------------------------------------------------------------------
On 2008-03-07T07:49:37+00:00 Stephan Adig wrote:
hi,
(In reply to comment #61)
> (In reply to comment #60)
> > So, as a package maintainer, what should I do? Someone needs to point me to a
> > patch for Wine or a patch for fontforge that I can ask to be merged in.
>
> As a package maintainer you could use an older fontforge version known to
> produce correct Wine fonts.
>
You can't. You use what your distro gives you.
If this version of fontforge is broken, you can try to upgrade, and hopefully nothing else will break.
Or you stay with the issue until the next release cycle.
Reply at: https://bugs.launchpad.net/fontforge/+bug/199331/comments/63
------------------------------------------------------------------------
On 2008-03-07T10:50:16+00:00 S-wezel wrote:
(In reply to comment #60)
> From a practical standpoint, Ubuntu Hardy is coming out soon, and while Wine
> can be patched at any time before release I believe the version of fontforge
> might be set. We may want to have a workaround anyway.
>
> Then again, Ubuntu is not opposed to patching fontforge if the changes we get
> are minimal enough.
>
> See Launchpad bug: https://bugs.launchpad.net/bugs/199331
>
>
> So, as a package maintainer, what should I do? Someone needs to point me to a
> patch for Wine or a patch for fontforge that I can ask to be merged in.
>
you could use my workaround until a proper fix exist:
http://bugs.winehq.org/attachment.cgi?id=10629
Reply at: https://bugs.launchpad.net/fontforge/+bug/199331/comments/64
------------------------------------------------------------------------
On 2008-03-07T11:44:02+00:00 Dmitry-baikal wrote:
(In reply to comment #62)
> hi,
> (In reply to comment #61)
> > (In reply to comment #60)
> > > So, as a package maintainer, what should I do? Someone needs to point me to a
> > > patch for Wine or a patch for fontforge that I can ask to be merged in.
> >
> > As a package maintainer you could use an older fontforge version known to
> > produce correct Wine fonts.
> >
> You can't. You use what your distro gives you.
If you can't use a fontforge version different from your official distro one
then your Wine packages will be broken, and you will have to cope with all
bug reports of your users on your own.
Reply at: https://bugs.launchpad.net/fontforge/+bug/199331/comments/65
------------------------------------------------------------------------
On 2008-03-07T19:34:47+00:00 WanderingVillager wrote:
The Debian package has worked around it since 0.9.53...
Reply at: https://bugs.launchpad.net/fontforge/+bug/199331/comments/66
------------------------------------------------------------------------
On 2008-03-14T13:55:09+00:00 Dmitry-baikal wrote:
It's been reported that fontforge-20080302 creates correct marlett.ttf.
Reply at: https://bugs.launchpad.net/fontforge/+bug/199331/comments/68
------------------------------------------------------------------------
On 2008-03-14T13:56:03+00:00 Dmitry-baikal wrote:
This bug can be closed as invalid.
Reply at: https://bugs.launchpad.net/fontforge/+bug/199331/comments/69
------------------------------------------------------------------------
On 2008-03-15T07:10:20+00:00 Scott Ritchie wrote:
Marking wontfix (for Wine).
Please use workarounds in packages for the meantime, and if you can
please provide a proper fix for fontforge - we certainly owe them a lot.
Reply at: https://bugs.launchpad.net/fontforge/+bug/199331/comments/70
------------------------------------------------------------------------
On 2008-09-17T13:51:27+00:00 Austin English wrote:
Closing WONTFIX.
Reply at: https://bugs.launchpad.net/fontforge/+bug/199331/comments/71
------------------------------------------------------------------------
On 2012-02-23T21:24:34+00:00 Austin English wrote:
Removing deprecated 'All' Platform.
Reply at: https://bugs.launchpad.net/fontforge/+bug/199331/comments/72
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to fontforge in Ubuntu.
https://bugs.launchpad.net/bugs/199331
Title:
Changes in fontforge cause Wine's marlett.ttf to have incorrect
available character sets
Status in FontForge - An outline editor for fonts:
Won't Fix
Status in “fontforge” package in Ubuntu:
Won't Fix
Status in “wine” package in Ubuntu:
Fix Released
Bug description:
Binary package hint: fontforge
Wine builds its fonts using fontforge in an unusual way. As it turns
out, the fontforge developers considered this a bug and fixed it in
version 20071210, resulting in a regression in Wine.
This change has been reverted in newer releases of fontforge, however
the weird behavior remains. As it stands, the versions of Wine and
fontforge we have are incompatible. So we need to either update
fontforge, patch Wine, or both.
The bug in Wine's bugzilla has more information about the problem:
http://bugs.winehq.org/show_bug.cgi?id=10660
To manage notifications about this bug go to:
https://bugs.launchpad.net/fontforge/+bug/199331/+subscriptions
More information about the foundations-bugs
mailing list