Apache OpenOffice (AOO) Bugzilla – Issue 15444
Wrong PDF export of Japanese punctuation char's
Last modified: 2013-08-07 15:00:08 UTC
Thanks for offering a nice Office suite. PDF export is useless in effect for Japanese users, because with 1.1beta2 on Windows2000 and WindowsXP, horizontally flowing Japanese punctuation characters are exported incorrectly. The expected PDF, msword.pdf, is attached as a reference. OO.o exports writer_2k.pdf on Win2K and writer_xp.pdf on WinXP from punct_flow_xp.sxw (only page 2 is shown). The problems are: 1) period and comma (A-1,2,F-4,5) are shifted as if they were written in vertical flow. 2) parentheses, brackets, and dashes (A-7, B-0,1,4,6,7, F-0,1,2, B-3, C-2, D-0,6,7) are rotated as if they were written in vertical flow. This issue appear in Impress as well as in Writer. This issue appears similar to issue #12150 with Chinese. That's why I first nominate HDU for this issue. Please integrate this issue into #12150 if it's appropriate. Attached file: punct_flow_xp.sxw ... Writer document writer_2k.pdf ... PDF exported on Win2K writer_xp.pdf ... PDF exported on WinXP msword.pdf ... reference PDF with the same content
Created attachment 6757 [details] Archive of related files
I guess it is the same as issue is exactly the same as issue #11938.
This issue is really serious and I would definitely like it to be fixed by OO.o 1.1. I meant issue #15120 above, instead of 12150. Not sure this is the same as #11938. This issue occurs even when the font has the characters in it. According to dev@qa message from pgm mgr, I add oooqa keyword.
PDF export is very important function. If PDF export has this error, japanese user can't use PDF export.
Reassing to QA first.
Herbert Duerr, Thanks for your advice. How can we reassign to QA? By changing the component from l10n to qa?
Hi, there is a good news. This message came from one of ja members. ---- I confirmed that the bugs also existed in Japanese StarSuite 6.1 beta and RC1, and they have been fixed according to the request of Sun Japan. So I think there's no difficulty to integrate existing fixes of StarSuite into OpenOffice.org about the Japanese PDF output problems. ----- Would you please contact with StarOffice development team about this ?
Showing off value-added proprietary product over open-source version? I didn't expect IssueZilla is a place for Sun-insider to sell SO/SS.
I compared "OpenOffice.org1.1beta2" with "1.1rc (vcl13 applied)". Incorrect position of Japanese commas and periods and 90-degree spinning of brackets and macrons in PDF outputs. http://www.transwift.net/ooo/11rc_pdf_vcl13_e.html Summary: Problems================Commas and Periods======Brackets=======Macrons===== 1.1beta2Horizontal======Incorrect===============Spinning=======Spinning==== 1.1beta2Vertical========Correct=================Spinning=======Correct===== 1.1rc(vcl13)Horizontal==Correct(+)==============Correct(+)=====Correct(+)== 1.1rc(vcl13)Vertical====Incorrect(-)============Correct(+)=====Spinning(-)= =========================================================================== (+)Improved (-)Regression
Above 1.1rc with vcl13 applied uses: gsl/ vcl/ source/ gdi/ outdev3.cxx gsl/ psprint/ source/ printergfx/ glyphset.cxx gsl/ psprint/ source/ fontmanager/ fontmanager.cxx gsl/ psprint/ inc/ psprint/ fontmanager.hxx from cws_srx645_vcl13
Now I've found that 1.1rc behaves almost the same as 1.1rc with vcl13 applied in terms of PDF outputs. Let me adjust my summary above. Summary: Problems================Commas-and-Periods======Brackets=======Macrons===== 1.1beta2Horizontal======Incorrect===============Spinning=======Spinning==== 1.1beta2Vertical========Correct=================Spinning=======Correct===== 1.1rcHorizontal=========Correct(+)==============Correct(+)=====Correct(+)== 1.1rcVertical===========Incorrect(-)============Correct(+)=====Spinning(-)= =========================================================================== (+)Improved (-)Regression
This problem on PDF outputs with "vert" feature only occurs on Win32 platforms. I've got valuable infomation on this feature in Win32 platforms from Herbert Duerr@gsl, who said: "On W32 platforms it is assumed that the OS's GDI layer handles these transformations when the vertical writing mode is set for a font. " As long as I have seen, 1.1beta2 and 1.1rc behave different on PDF outputs on my same Windows98SE machine. http://www.transwift.net/ooo/11rc_pdf_e_utf8.html So I am compelled to think that something has changed from 1.1beta2 to 1.1rc. I would like to know what code have changed and how on OOo's code side? What mechanism does OOo use to perform PDF exports? Is this feature implemented as printing function, or Export Filter ( http://xml.openoffice.org/filter/ )? Should "component" be changed from l10n to something else? And can http://www.openoffice.org/issues/show_bug.cgi?id=11579 be linked or merged to this issue here? I really want this issue to get fixed in 1.1RC2 for Windows. Thanks
HI->HDU: Verified with 645m9s2-5_8650_81. - Printing to a PCL or PS printer works. - When I set the fonts to ARIAL UNICODE MS, the PDF-Export looks good. With this reason I set the target to 2.0 and see this issue as not a showstopper.
Since this issue #15444 focuses on PDF Export in Horizontal Writing, this can be closed, I think, because it seems that problems have been fixed in 1.1rc. On PDF Export in Vertical Writing, please refer to: http://www.openoffice.org/project/www/issues/show_bug.cgi?id=11579 Thanks.
HDU->US: I agree with the suggestion above to close this and use issue 11579 for problem of the vertical PDF export. Please verify for horizontal PDF export and close.
transferring to hi.
Set as dublicate to 11579 *** This issue has been marked as a duplicate of 11579 ***
Closed