Issue 87669

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