http://bugs.winehq.org/show_bug.cgi?id=15314
Summary: winhelp: transition to richedit breaks minigolf1997.hlp file Product: Wine Version: 1.1.4 Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: richedit AssignedTo: wine-bugs@winehq.org ReportedBy: hoehle@users.sourceforge.net CC: eric.pouech@orange.fr
Created an attachment (id=16145) --> (http://bugs.winehq.org/attachment.cgi?id=16145) 11 year old minigolf.hlp file, broken display since wine-0.9.61
MINIGOLF.HLP is displayed incorrectly in 1.0 and 1.1.4, whereas 0.9.16 and 0.9.57 worked. More precisely, winhlp32 displays roughly 6 odd chars instead of all text. The 6 index entries are shown correctly, though.
An educated-guess regression testing (reading about richedit while looking for duplicates) located the cause between wine-0.9.60 and .61 in commit 9b24f2a0507d173e65641649a70fced300afab26 bad winhelp: make richedit the default for rendering, on 2008-04-28. This version still had the ability to switch renderer via $WINHELP_RICHEDIT, which got lost in "Get rid of the old internal rendering" on 2008-05-01. Via this variable, I could very that this transition indeed causes the bug.
The file (11kB) is attached.
http://bugs.winehq.org/show_bug.cgi?id=15314
Jörg Höhle hoehle@users.sourceforge.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression, source
http://bugs.winehq.org/show_bug.cgi?id=15314
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download
http://bugs.winehq.org/show_bug.cgi?id=15314
Eric Pouech eric.pouech@orange.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |FIXED
--- Comment #1 from Eric Pouech eric.pouech@orange.fr 2008-09-20 14:48:00 --- fix sent to wine-patches A+
http://bugs.winehq.org/show_bug.cgi?id=15314
Dmitry Timoshkov dmitry@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |UNCONFIRMED Resolution|FIXED |
--- Comment #2 from Dmitry Timoshkov dmitry@codeweavers.com 2008-09-23 01:25:56 --- The bug should be marked as FIXED only when the patch has been committed.
http://bugs.winehq.org/show_bug.cgi?id=15314
Eric Pouech eric.pouech@orange.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|eric.pouech@orange.fr |
--- Comment #3 from Eric Pouech eric.pouech@orange.fr 2008-09-23 14:06:29 --- issue is about improper string handling when emitting the RTF code for broken hlp files the string (face name of the font in that case) should be properly truncated to avoid bad rtf (especially ASCII-control characters and specific characters in RTF)
for the sake of record a fix is here: http://www.winehq.org/pipermail/wine-patches/2008-September/061871.html
whoever feels free to make it pass the discriminatory gates of wine-patches is free to do it
http://bugs.winehq.org/show_bug.cgi?id=15314
--- Comment #4 from Jörg Höhle hoehle@users.sourceforge.net 2008-10-14 04:26:55 --- Eric, Thank you for the patch, it worked with the .hlp file.
make it pass the discriminatory gates of wine-patches
Did you mean that your fix was rejected for unknown reasons?
I believe a fix in this area is necessary, to escape the garbage-in -> garbage-out cycle: the RTF generated by Wine must be correct, even when the .hlp may be partly broken, like you say. So a fix is needed, no debate.
However, I wonder whether your check if (!ch || !isalpha(ch)) break; is a good one.
1. '-', ' ' etc. may be found in font names. isprint() maybe adequate instead.
2. AFAIK, LogFont.lfFaceName is subject to some encoding (which one is used?), so I don't know whether the UNIX locale used by isalpha()/isprint() is appropriate. BTW, I read in WineLoc that MS produced fonts with native CJK names, obviously non-ASCII.
Is there some helper function in wine to determine whether a string is correctly encoded?
Why did you make your patch abort the loop upon encountering illegal characters, yielding a partial font name? Don't you think it would be "better" (somehow?) to just skip a fontname directive entirely when a broken name is encountered?
http://bugs.winehq.org/show_bug.cgi?id=15314
Jörg Höhle hoehle@users.sourceforge.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |FIXED
--- Comment #5 from Jörg Höhle hoehle@users.sourceforge.net 2009-03-04 01:55:10 --- This is not an issue anymor since (at least) 1.1.11.
The trace reveals that WineEngCreateFont now substitutes the broken font name L"$\0011\00ff\0013e\0004p" with Tahoma.
http://bugs.winehq.org/show_bug.cgi?id=15314
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #6 from Alexandre Julliard julliard@winehq.org 2009-03-13 11:15:40 --- Closing bugs fixed in 1.1.17.
-
wine-bugs＠winehq.org