Apache OpenOffice (AOO) Bugzilla – Issue 21821
Problems with combining diacritical marks unicode range
Last modified: 2005-01-21 23:15:04 UTC
Hi! First of all: this is my first bug submit - I hope I am not completely at the wrong place... please excuse me! All characters of the unicode subrange "combining diacritical marks" suffer from display and printing problems. They are not printed in all text, spreadsheet and draw documents (instead, a rectangle is printed - my printer is a Canon S500). A huge gap appears after a diacritical mark: - when opening a ooo1.0 text document (new ooo1.1 text docs work well) - in the page preview of spreadsheet documents. (I may provide sample documents.) I hope this helps you... Yves Scherrer
Yes, please attach sample docs. It´s easier for us to reproduce the problem. Thanks.
Created attachment 10870 [details] text document in which the diacritics are not displayed and printed correctly
Created attachment 10871 [details] another test file with slightly different problems (described in the file)
Created attachment 10872 [details] a spreadsheet file that contains the reported display and printing problems
I can confirm that this is true with the attached files in 1.1.0 under XP. I don't believe it's a font problem. However I do wonder how the characters were entered. e.g. keystrokes, special char ...
Reproducible with OOo1.1 on Windows 2000. Regression: In OOo1.0.1 combined diacritics work with "Lucida Unicode" font. In 1.1 spacing is wrong. confirming.
please provide a screenshot of the wrong display. Looks OK on linux - although you're not using "standard" umlauts (maybe this is intended). You write that new documents work, old documents don't so I bet the setting "use printer metrics to format document" causes this behaviour. Try to turn this off (Tools|Options->Text Docment->General->Compatibility) as a workaround you can use the pdf-export and print that pdf (but you should look for a update for your printer driver - if you're using a localized version try installing the english driver, these usually have fewer bugs)
I have just tested this with OO.o 1.1 under Mandrake Linux 9.2 + KDE 3, and it appears to work perfectly. The diacritics are alligned correctly, spacing is correct, and it appears fine in Preview. All files print fine. When I installed my system, I set it to use Unicode by default. This leads to the conclusion that the problem is more likely in the Windows Unicode handling than in OO.o itself, as everything is fine even with Thorndale as the font, which is not installed on my system. Whatever the cause, it seems to be Windows-specific.
Thanks for the "use printer metrics" hint. It seems that this option causes some of the problems (the gaps appear when the option is enabled and disappear if it is disabled). I have done some more tests - here the results: text component: - normal view: gaps depend on printer metrics option - print preview: gaps depend on printer metrics option - pdf export: gaps depend on printer metrics option spreadsheet component: - normal view: gaps depend on printer metrics option - print preview: always with gaps - pdf export: never with gaps presentation and graphic component: - normal view: gaps depend on printer metrics option - pdf export: gaps depend on printer metrics option Printing problems appear in all cases. Some words about the attached files: - File 1 and 2 differ only in that in 1 the printer metric option is enabled and in 2 it isn't (it doesn't matter in which ooo version they were created as I suspected initially). - I'll attach a screenshot of what the printer output looks like. I produced it with an Apple LW postscript driver, so this issue seems to be printer independent.
Created attachment 10963 [details] screenshot of the display errors
Created attachment 10964 [details] screenshot of what printer output looks like
TM->US: Please have a look. I don´t really know, if it is your turn to have a look or HI`s. Thanks !
This _IS_ a font issue (and admittedly a glyph substitution issue). When combining characters you should make sure to use the same font for the basis character as for the diacritical mark (which is obviously not always the case in the bugdoc). If this is not the case or the font where the diacritical marks are taken from does not exist on the viewers mashine it comes to a glyph substitution. Obviously this does not look perfect (combining two glyphs to one character from different fonts - ouch). If characters are printed with squares, which I couldn't reproduce (neither wrong character spacing) this indicates a glyph substitution mismatch on the printer device (don't get me wrong, I don't blame it on the printer). If the problem with squares on the printout persists pls. add a detailed list of your installed fonts and attach your printer driver to this issue. Thx. BTW. if you really have the need for such diacritical marks (and not just playing around) you should also have full featured fonts so that no glyphsubstitution becomes active. Taken into accoount that OOo uploads the glyphs of the used fonts (as so called Type 42 fonts) to the printer, I can hardly imagine squares on the printout. => WFM.
I apologize for my typographical crime, but this is absolutely not the point: All errors persist still if the document contains only one font (Lucida Sans Unicode). It seems to be quite independent of the printer driver: I have tried some post script drivers that come with Win2k as well as the PS driver from Adobe and my Canon inkjet driver: squares everywhere. Then, I have reinstalled OOO on a system that contains only the standard MS fonts (see attachment for the list), and all problems still remained. So I don't really know where the problem is; maybe we can get help from those who could reproduce the error? (CC added: grsingleton, jensja).
Created attachment 11265 [details] the list of my fonts
Created attachment 11266 [details] a post script file produced with the adobe generic driver, contains squares
I don't get the adobe printer driver uploaded, but you can download it at the following address: http://www.adobe.com/support/downloads/product.jsp? product=44&platform=Windows BTW: I do need diacritical marks (but not very often, I admit it). They are handy if you need to describe a language or a dialect for which the standard characters are inappropriate or not exact enough...
Ok, will reinvestigate. Maybe GlyphSubstitution runs amok on Win2k (which would possibly be a duplicate --don't have the ID at hand for the moment). Unix is innocent.
My apologies. Yes we have (had?) problems with zero width characters. US->HDU: probably duplicate (21951?).
Reassigned to HDU.
Yes, zero width glyphs incorrectly triggered the heuristicts for glyph fallback on the win32 platform. Fixed in CWS fontlists02 for target OOo 2.0.
An additional problem was the non-1:1 char<->glyph mapping when diacritical marks are used => need to apply CTL processing Fixes are in CWS fontlists02 for target OOo 2.0
reopening for reassignment
reassigning for verification
HDU->US: please verify in CWS fontlists02
Verified in cws fontlist02.
This fix is already implemented since 680m48. I verified it also with 680m55_8811. Still ok -> Closed.
*** Issue 27930 has been marked as a duplicate of this issue. ***
*** Issue 41107 has been marked as a duplicate of this issue. ***