Apache OpenOffice (AOO) Bugzilla – Issue 87669
oowriter formula pdf export turns numbers into Arabic/hindi
Last modified: 2009-12-10 21:10:36 UTC
When exporting an .odt with formula objects, some of the digits in the formulas get turned into Hebrew(?) characters. It appears to be random what numbers get replaced and what don't. I've tried several different PDF export options and it only succeeds in changing the randomness. Changing the base document appears to change the randomness somewhat. I did have one export that didn't have any replacements, but reading through it (looking for oddities) I noticed a mistake and changed the original document. Several dozen attempts since resulted in varying levels of random replacement of numbers. This is the first export I've done in 2.4, and I don't think I ever saw anything like this in 2.3. Attachments forthcoming.
Created attachment 52411 [details] odt all pdfs were generated from (ignore my silly math homework)
Created attachment 52412 [details] first PDF generated, no checkboxes selected in export window
Created attachment 52413 [details] 'PDF/A-1' only checked
Created attachment 52414 [details] 'tagged' only checked
Created attachment 52415 [details] 'tagged' only checked (exported moments after 'Tagged.pdf' but different replacements)
I changed the title after a friend confirmed that the numerals are being replaced with Arabic character equivalents.
Created attachment 52417 [details] simple copied/pasted series of numbers in 'formula' object
Created attachment 52418 [details] the export, with whole objects converted to Arabic
Ok, instead of uploading a bunch more files, I've put all the files on my webserver, the url is in the URL box above and is : http://widgetron.net/ooops/ in case that's not the right place.
Reassigned to HI.
I know it isn't the same issue, but could this be related to issue 86811?
Hi->HDU: Could not reproduce, please have a look.
Yes, it most probably has to do something with issue 86811. Why only PDF export seems to be affected in this case is an open question though that can be probably answered easily when 86811 is solved.
->HDU I think issue 55160 describes the reverse problem (see the end of the description).
kaplan -> psychoi3oy: I can't reproduce the bug on 2.4.0 from Debian GNU/Linux. Please contact me privately so we could try and reproduce it.
I have the exact same problem: the PDF generator is converting old Arabic numbers, e.g., 1,2,3, in formula objects into new Arabic numbers, e.g., not 1, 2, 3. I can attach numerous examples, but I am sure that psychoi3oy has enough. This is also the OO release that comes standard on Ubuntu release 8.04 (hardy). My question is, is this happening to non hardy users or only to people who are running x64 hardy? This has never happened in 2.2 as far as I know.
I see the same behavior in 2.4.1.5 Gentoo x86_64
I forgot to check right after upgrading to 2.4.1 but I can confirm now that 2.4.1 is doing the same thing to me. Apparently it wasn't tied to 86811.
I checked with "2.4.1 Multilingual version German UI WIN XP: [680m17(Build9310)]" and it seems that I can NOT reproduce the reported effect.
I just removed 2.4.1 and emerged (yes, I'm also on Gentoo 64bit if I didn't mention that before) openoffice-bin 2.4.0 and did NOT have the same issue. I wonder if it's a problem with the compiled versions or even with Gentoo or something in the 64bit or ???? So, we have confirmed non-problems in 2.3, 2.4.0/linux (binary in Gentoo and Debian), 2.4.1/win32 We have confirmed problems in 2.4.0/linux source (amd64 gentoo), 2.4.?/linux Ubuntu (presumably bin but???), 2.4.1/linux source (amd64 gentoo), and 2.4.1.5/gentoo amd64(source or -bin?). I'll go poke around the Gentoo forums to see if anyone there has the same issue if it is tied to Gentoo / source only.
I am using the source build NOT the binary. (Gentoo x86_64, openoffice2.4.1.?) And as reported I do have this problem. In gentoo the associated reported issue is 228407 Have rebuilt and checked in 2.4.1.5 and 2.4.1.8 both have this issue.
Can't reproduce your issue with official version (OOo 2.4.1 Sun) under xubuntu Hardy. So this is certainly linked to your distribution. Can you install the official (Sun) version with the tarballs on the OOo website?
I'm having the same problem on opensuse 11 64bit and OpenOffice 2.4.1.10. exporting the document again and again finally creates a clean document. this makes productivity fall a notch.
I can confirm this problem for OOO300m7 (Build:9354) (retrieved from http://download.opensuse.org/repositories/OpenOffice.org:/UNSTABLE/openSUSE_11.0/i586/OpenOffice_org-3.0.0.3.2-2.1.i586.rpm and related packages). In my case, some formulas have arabic digits while some formulas have european digits. For subsequent export runs, the "arabicness" of the digits changes. It looks like the "arabicness" is random or depends on the particular time of the export.
A note about my system: It is running OpenSUSE 11.0 and the kernel is like this: Linux notebook 2.6.26-4GB #4 SMP PREEMPT Thu Jul 24 23:58:11 CEST 2008 i686 i686 i386 GNU/Linux Judging from the behaviour, I would suspect the following: There is some cacheing of fonts in a LRU list or maybe in a hashtable. Both the european digits and the arabic digits are chosen as eligible by some algorithm.The problem can only show up on systems where fonts are actually installed which provide arabic digits. The problem happens when the algorithm does a read access on a font data structure to retrieve the font or the glyph for a particular digit (or a particular formula), but some caching-subsystem makes the read-access have side effects, like reordering an LRU list or something. The next time the read access is done, a different font is returned.
*** Issue 87669 has been confirmed by votes. ***
I saw this bug immediately using the numbers.odt file posted here and the version of OpenOffice 2.4 in Ubuntu Hardy. After downloading the .deb files for OOO300m9 from openoffice.org and installing it, I did not continue to see this bug. Strange that it affects so many distributions, but seemingly is not reproducible using Sun's openoffice. My votes confirmed this issue, but that was before I saw that it didn't seem to be present in Sun's binaries.
same here at 3.0.1, it starts to really annoy.... gentoo, self compiled
I tested both ODT files uploaded to the bug, and I couldn't reproduce the problem. I'm working with 3.1 from Debian unstable (ooo310m11). If needed you're welcome to contact me in private to test more files.
I do not experience this problem with OOo 3.0.1 on Ubuntu 9.04. Tried both .odt files and the export worked well.
Created attachment 62177 [details] odt file
im using OO 3.1 OOO310m11 build 9399 my system is ubuntu 9.04 (recently upgraded from 8.10). and the numbers.odt file still makes that bug whene trying to export to PDF. sampleMath.odt works grate. i have also add two more files one is a ODF file and the other is an exprted PDF. the ODF file was edited on ubuntu 8.10 and ubuntu 8.04 but the PDF was exported on ubuntu 9.04 hope this could help.
i can confirm that the first (sampleMath.odt) attachment is converting hindi numbers to arabic when exporting to pdf. while the last attachment (work_2.odt) exports to pdf just fine. i use Debian unstable 64bit with OOo 310mm9
Created attachment 62178 [details] the PDF file
can't seem to reproduce this bug (tried both sampleMath.odt and Work 2.odt). I'm using OpenOffice v3.0.1 on Ubuntu 9.04
Created attachment 62263 [details] The PDF I'm getting. Has Strange Characters in the last equation (Mandriva Cooker with OOo 3.1)
Like I said, in my last attachment, I got strange characters in the PDF in the last equations. Checked with both kghostview and evince. Otherwise, everything seemed fine.
@tl: Do you have a clue what might cause this?
tl->hbrinkm: No. Aside from the issue already mentioned by HDU I have no idea yet.
I have the same type of problem on Ubuntu 9.04 (64-bit) with the Ubuntu OpenOffice (3.0.1). Upon PDF export, some numeric characters in Math equations are replaced, especially in sub and superscripts. Using a colleague's OpenOffice 3.1.0 on Windows XP, no PDF export problem was encountered and the math looks normal. For now, I will use this method to generate PDF, while waiting that hopefully the problem will be solved in Ubuntu OpenOffice 3.1.1 which appears to be included in the upcoming Ubuntu 9.10.
I am 90 percent certain that debian and ubuntu use go-o, the non-official fork. For this version, I have had the same bug introduced amongst others.
Is it possible to make clear for OOo devs if the problem is with official build (Sun) or not? If it can't be reproducible in Sun build, then this report is invalid.
I couldn't reproduce the problem with both sampleMath.odt and numbers.odt on oo.org 3.1.1 (ooo310m19, build 9420). I tested using the sun 3.1.1 version on windows XP, and debian's oo.org 3.1.1-5 packages (based on go-oo).
i could not reproduce the bug with the SampleMath.odt file nor with the numbers.odt file but the work 2.odt gives me the same problem as before im using OO 3.1.1 OOO310m19 Build:9420 under Ubuntu 9.10
In my case the bug seems specifically related to Ubuntu OpenOffice 3.0.1 on 64-BIT 9.04. I do not experience the problem on Ubuntu OpenOffice 3.0.1 on 32-bit 9.04, nor on official OpenOffice 3.1.x on Windows XP. Perhaps things will be better on 9.10 (64-bit)... Sorry if this issue is not intended for the 'official' OpenOffice QA.
I can confirm the issue (Mandriva 2009.1, OOO 300m15 (Build:9379)). The same issue exists in Impress. I haven't experienced the issue in Windows builds. Also, I have noticed that enclosing the numbers in double quotes seems to eliminate the problem (e.g., putting "2" in the formula editor instead of 2). I hope this helps, the issue is very annoying when working with large amounts of math.
I have suffered this problem for a long time, and still have the same issue with 3.1.1 under Kubuntu 9.10 64 bit. A workaround in (K)ubuntu (and other flavours of Linux) is to use the "print to file" option in the print menu. The resulting pdf has poorer resolution and takes nearly 4 times the space than the highly efficient OO export, but at least the fractions and exponents come out correctly. As a maths teacher producing exam papers this is a major bug for me.
I saw no Hindi numbers when checking this on CWS vcl108. *** This issue has been marked as a duplicate of 107358 ***
duplicate -> closed