Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
Summary: | Some letters are omitted when printing | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | gsl | Reporter: | alexps <alex-kostjukov> | ||||||
Component: | www | Assignee: | h.ilter | ||||||
Status: | CLOSED FIXED | QA Contact: | issues@gsl <issues> | ||||||
Severity: | Trivial | ||||||||
Priority: | P2 | CC: | hdu, issues, rb.henschel | ||||||
Version: | OOO310m19 | ||||||||
Target Milestone: | OOo 3.2 | ||||||||
Hardware: | PC | ||||||||
OS: | Linux, all | ||||||||
Issue Type: | DEFECT | Latest Confirmation in: | --- | ||||||
Developer Difficulty: | --- | ||||||||
Issue Depends on: | |||||||||
Issue Blocks: | 99999 | ||||||||
Attachments: |
|
Description
alexps
2009-11-11 20:07:21 UTC
Created attachment 66069 [details]
Files noted in description
Both printing on HP LaserJet and exporting to pdf with an Englisch OOo on German WinXP have _no_ errors. The problem is probably related to issue 104050 and issue 105631#desc14 Created attachment 66073 [details]
Another sample, more simple, only 1 letter involved
The samples' zip posted above include odt file with only Cyrillic “Shot I†(U+0419) in Arial and “Print into file†postscript output. It is clearly seen with postscript file that the only one letter to be printed has no encoding defined in the embedded font subset. There is strange “Encoding 0†bound to glyph3 only in the file. Glyph3 looks like an empty rectangle. Glyph1 and glyph2 that pulled into embedded font subset are parts of Cyrillic “Shot I†(U+0419) – the letter that should be printed. “Short I†(http://en.wikipedia.org/wiki/Й) consists two graphical parts – the base that looks the same as other Russian letter “I†and the diactrical mark – breve. Glyph1 is the base and glyph2 is the breve. HIGH IMPORTENS FOR RUSSIAN USERS! It is very important for Russian users, because they can not print in Open Office documents in MS Winword format, which is the de facto standard for government agencies and corporations in Russia I can confirm that the second sample doc creates only ony glyph encoded as "0" in the produced font. However ghostscript seems to show this PostScript file just fine (including the sample postscript output attached). A PDF file produced with cups-pdf shows just fine in acroread; only ghostscript shows a problem with that PDF file. Anyway, let's try to avoid glyph 0 and use 1 instead. Ok, what is wrong is the Encoding vector (and is plain wrong, the actual encoded value for the glyph is already '1' as it should be). The Encoding vector however seems to be not the first place most programs look for the glpyh, it seems to be the CharStrings array. The entries of the encoding vector are originally created in vcl/unx/source/printergfx/glpyhset.cxx in GlyphSet::PSUploadFont. The encoded entries come from a hash_map, which is not sorted; but that should not be necessary anyway since the decription comes as a glyph array and an encoding array. This then goes into FontSubsetInfo, which uses CreateT42FromTTFont (and friends) to create the subsetted font file. Now the latter expect the notdef glpyh to be encoded '0' (which is reasonable), but do not allow for the encoding to be unsorted. So there are three places where the encodig -> glyph could be repaired by sorting: PSUploadFont (which has the original unsorted data), FontSubsetInfo (which uses CreateT???FromTTFont wrongly) or the CreateT???FromTTFont functions, which perhaps should be able to catch this. @hdu: do you have an opinion where to best fix this ? I chose to use CreatePSUploadableFont in glyphset.cxx for this since it is central and allows to use the unsorted hash_map in the GlyphSet class (which is probably a performance gain). Anyway I'd like you to review the change. fixed in CWS vcl108 *** Issue 104050 has been marked as a duplicate of this issue. *** *** Issue 105631 has been marked as a duplicate of this issue. *** Doing it in CreatePSUploadableFont() is the solution that will solve this problem reliably and without the risk to impact other parts of the code. The need to put the Notdef glyph at glyphid zero is needed and coded all over the place though so in the medium term I'd love to have all this consolidated into one place like FontSubsetInfo::CreateFontSubset(). I'm not sure though what all the callers are expecting since they provide a const parameter to request the id of each subsetted glyph. Are these just friendly suggestions that can be completely ignored or can they be reshuffled at will by the callee? As of now the subsetter will treat them as gospel and does just as requested. will also commit to CWS ooo32gsl09 for 3.2 due to the overall severity for printing on Linux. please verify in CWS ooo32gsl09 Bug was not reproducible on my suse linux. Fix verified on PL's machine. @alexps: Please close this issue when it is still ok in OOo3.2 final. |