[ooo-build] [amd64] bad numbers after creating pdf

[Roland Satlow]

Converting a document with formulas and schedules to PDF causes various errors in numbers. (They seem to be hebrew or so instead of arabian).
At each conversion, different numbers are affected, the former incorrect ones get partially correct.

With OpenOffice.org-i386 everything works well, so only the AMD64 version seems to be affected.

System: Ubuntustudio 8.04
Package: openoffice.org 1:2.4.0-3ubuntu6

ProblemType: Bug
Architecture: amd64
Date: Fri Oct 10 09:25:00 2008
DistroRelease: Ubuntu 8.04
Package: openoffice.org-core 1:2.4.0-3ubuntu6
PackageArchitecture: amd64
ProcEnviron:
 PATH=/usr/lib/openoffice/program:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
 LANG=de_AT.UTF-8
 SHELL=/bin/bash
SourcePackage: openoffice.org
Uname: Linux 2.6.24-19-generic x86_64

[Chris Cheney (ccheney)]

Can you attach the original document that exhibits this problem to the launchpad bug report? The one you attached the PDF of...

[Roland Satlow (m0035096)]

This is the .odt file i converted to pdf.

[Chris Cheney (ccheney)]

Created an attachment (id=248731)
file exhibiting problem

Converting a document with formulas and schedules to PDF causes various errors in numbers. (They seem to be hebrew or so instead of arabian). At each conversion, different numbers are affected, the former incorrect ones get partially correct. This appears to only happen on x86-64.

[Rodo (rodo)]

I was able to replicate it with 3-0 branch as well as with trunk.

[Kendy (kendy)]

64bit, I'll take this one ;-)

[Chris Cheney (ccheney)]

I think this might not actually be 64bit specific as I found another bug report related to this which is for i386...

https://bugs.edge.launchpad.net/bugs/244353

Exporting this simple file as PDF causes the second half of the numbers to convert from arabic to hebrew.

http://launchpadlibrarian.net/15698985/test.odt

This still occurs with ooo-build-3-0-1.

[Carlo-strata (carlo-strata)]

I use OpenOffice.org (OpenSuSE) x86-64 (!!!) build from here (yast2 yum style repository)
http://download.opensuse.org/repositories/OpenOffice.org:/STABLE/openSUSE_11.1/

on an x86-64 system (now daily updated 11.1, but since 10.0).

1)
Since OO.o 3.0 in exporting each file (also a simple one word odt) in pdf/A-1 format and reading it in a Microsoft Windows XP/Vista system with Adobe Acrobat Reader (9.x), Acrobat Reader complains about invalid color space and keep the his windows empty (after closing his error/warning message dialog).

The same "bad" pdf, perfectly (!) opens and renders on Evince 2.24.1 or Okular 0.8.1/KDE 2.4.1 (all 64 bit builded apps).

2)
In the same OpenSuSE/OpenOffice notebook I also see pdf exported document (from a Writer document with some Calc tables with formulas in it) with number in the calc tables converted from arabic (e.g. "1", "23", "5.400,34", ...) to hebrew (I suppose). Not all the table were affected, but each table is either completely affected or perfect, interesting behavior...

This arabic/hebrew pdf opens and renders bad both on linux platform and Windows/Acrobat one.

I have just retested both problems with the 2009-03-07 build:
OpenOffice_org-3.0.1.3-1.1.x86_64.rpm 07-Mar-2009 06:26

(I choose a representative file). But all the problems still remain.

Hope that help.

Carlo

[Carlo-strata (carlo-strata)]

Addenda...

About 1) problem if I uncheck Pdf/A-1 export all exported documents read perfectly on all platforms.

I don't know if the experienced problems are related... But perhaps...

Carlo

[Kendy (kendy)]

Carlo: According to the comment 4, any chance to check on a 32bit system as well to be 100% sure if this is 64bit problem, or a general one?

Thank you in advance!

[Carlo-strata (carlo-strata)]

Jan: I will try to install a 32bit system and check it asap!

Than I will post here again!

Have a nice day,

Carlo

[Carlo-strata (carlo-strata)]

Created an attachment (id=280908)
simple odt file, created on a 64 bit Novell-OOo

I 'm submitting 6 little files to make evident pdf A1 errors only on 64 bit OSes.

Carlo

[Carlo-strata (carlo-strata)]

Created an attachment (id=280909)
Bad exported (!) 64 bit OOo A-1 pdf

[Carlo-strata (carlo-strata)]

Created an attachment (id=280910)
Well exported (!) 64 bit OOo A-1 pdf

[Carlo-strata (carlo-strata)]

Created an attachment (id=280912)
Well exported (!) 64 bit OOo normal (!) pdf

[Carlo-strata (carlo-strata)]

Created an attachment (id=280913)
Well exported (!) 32 bit OOo normal (!) pdf

[Carlo-strata (carlo-strata)]

Created an attachment (id=280916)
My OOo about window, with release and build versions

[Carlo-strata (carlo-strata)]

Created an attachment (id=280918)
Export of the issue original file (64 bit OOo, bad)

[Carlo-strata (carlo-strata)]

Created an attachment (id=280919)
Export of the issue's original file (32 bit OOo, good)

[Carlo-strata (carlo-strata)]

Now, some words...! ;-)

I have installed an updated OpenSuSE 11.1 32 bit system (P4, 1 Gbyte RAM).

I have make the export of the original issue file with both the 32 bit and 64 bit systems (Novell-OOo are identical source versions as stated on the single attached png file of the about window).

I have also exported my original odt file (with many object, calc tables, inside like original post file) in the 32 bit OOo.

In both cases, only 64 bit pdf export fails (hebrew fonts)!
-----------------------------------------------------------

I have attached both the pdf files (only those exported from the original issue file).

I also have attached a new odt simple text file and the four pdf (normal and A-1) exported from both platform (32 and 64 bit).

Only 64 bit pdf A-1 export fails!
---------------------------------

Are these issues originating from the same bug?

Hope that help.

Carlo

[Carlo-strata (carlo-strata)]

I close need info status.

[Carlos Sevcik (carlos-sevcik-s)]

In my case the bug happens only using Ubuntu OO not the original files downloaded from www.openoffice.org, I posted this elsewere:

[QUOTE]I am running Jaunty with OpenOffice.org 3.01 in 3 different machines, a Dell Workstation with dual Xeon processors, an HP laptop with a dual Centrino processor, and a small HP laptop with a dual AMD Turion64.

For some time now I have noticed that when I write a document with lots of equations in it, which look OK in the OO writer or its printouts, the digits (1,2,...,0) get more or less randomly distorted (replaced by a phony symbol) when the document is exported to pdf format. I first thought that it might have something to do with the fonts used (changing from Bitstream Vera Sans to Dejavu Sans or Nimbus Roman 9 makes no difference), but this was not the case. By more or less random I mean it might change from one conversion to the next, or appear only after page 13, while the equations from 1 to 12 might be OK (at least most of the times for that document).

But I recently realized that the bug appears only when I export to pdf in my small laptop (HP Pavillion tx1230la with memory expanded to 4 gB, AMD Turion64x2) and does not happen when exporting the same document using the same version of Ubuntu and OO in neither of the two other machines. The OO version installed in the 3 machines was installed using the Synaptic Package Manager provided by Ubuntu and from Ubuntu's repositories.

Furthermore, today I downloaded OO 3.0.1 from the OpenOffice.org site (Debian packages for x86-64 systems) and installed everything in the DEBS subdirectory using

sudo dpkg -i *

and to my surprise the conversions to pdfs in my HP Pavilion tx1230la seem to be working perfectly when I use the OO writer downloaded from the OO site directly.

My conclussion: There is a bug in the Ubuntu for x86-64 OO version which does not exists in the packages downloaded directly from the www.OpenOffice.org site.

Furthermore, I have the feeling that the bug is not new, I observed distorted digits in some of my manuscripts exported to pdf using Ubuntus's OO 2.x as early as 2 years ago, but was unable to pinpoint the problem as I did now. As said is a somewhat random problem.[/QUOTE]

[Carlos Sevcik (carlos-sevcik-s)]

I stick to my word, after exporting more than 10 documents in my AMD64 machine, which were buggy with the Ubuntu OO files, the bug showed in none of them using the original OOo built files.

[Chris Cheney (ccheney)]

Yep, hence why it is linked upstream to ooo-build (Go-OO.org) and not to openoffice.org.

Chris

[Carlos Sevcik (carlos-sevcik-s)]

I am not sure, but my guess is AMD64 Ubuntu's OO is compiled from source, and something is done differently than in OOo site. Different compiler? Different compiler version? It's hard to say, I don't know the innards of the process.

[Chris Cheney (ccheney)]

Er yea there is a lot different about the Ubuntu version it uses Go-OO.org ooo-build which has around 800 patches to fix various bugs and add features. It also occasionally has bugs of its own.

Chris

[Carlo-strata (carlo-strata)]

Hi Everyone!

We are going to solve this issue... :-)

I just perform some new tests with my documents and the official issue test .odt too.

I have just updated my OOo to version 3.1.0.2 from here:
http://download.opensuse.org/repositories/OpenOffice.org:/UNSTABLE/openSUSE_11.1/

My notebook is an updated OpenSuSE 11.1 x86-64 installation (Intel Centrino dual core 3 MByte cache, EM64T capable, 4 GByte RAM... an Acer Aspire 8920G). I opened my test document and the issue's official one and exported them to both pdf and pdf/A-1a.

My test viewers are:

- 32 bit Adobe Acrobat Reader 9.1.1 italian on 64 bit Windows Vista HP 64 bit italian;
- 64 bit evince 2.26.1 on gnome 2.27.x on OpenSuSE 11.1;
- 64 bit okular 0.8.3 on KDE 4.2.3 release 120 on OpenSuSE 11.1.

Both "pdf only" exports are now correct (yeah! ;-) ) on my 64 bit pc and correctly opens on each of the three test viewers.

Both "pdf/A-1a" exports open on linux viewers but maintain some Hebrew font characters while Acrobat Reader still complains about invalid color space and keep the his windows empty (after closing his error/warning message dialogs, some subsequent ones).

Now I post the two exported pdf versions of the issue test file.

Hope this help,

Carlo

[Carlo-strata (carlo-strata)]

Created an attachment (id=293691)
 Export of the issue's original file (64 bit OOo, pdf only, good)

I set obsolete three of my old attachments.

[Carlo-strata (carlo-strata)]

Created an attachment (id=293692)
Export of the issue's original file (64 bit OOo 3.1.0.2, pdf/A-1a, bad)

[Carlo-strata (carlo-strata)]

A final little consideration.

Are the two ("pdf only" and "pdf/A-1a") pdf export software "modules" sharing too few (!) coding lines so that a bug fixing in the first one doesn't fix the second one for the "same" behaviour part?

Are the two software "modules" better re-engineered together in a new one?! It seems to remember that an Italian coder develop the second one so I feel me particularly close to my fellow-citizen work.

Hope to give us interesting ideas! ;-)

Carlo

[Carlo-strata (carlo-strata)]

Hi Everyone!

I have just updated my OOo to version *3.1.0.4* from here:
http://download.opensuse.org/repositories/OpenOffice.org:/UNSTABLE/openSUSE_11.1/

I just perform some new tests with my documents and the official issue test
.odt too.

I have got the same results of my previous post (that for 3.1.0.2: pdf only perfect on all three test viewer and pdf/A-1a bad that opens only on evince and Okular) with some little differences:

- with my personal test document I got an embedded calc table object (in the fourth page and as first export error from the first page besides I have 5 or calc table object before this one) with all digits in numbers as an empty character (the classical empty square that stay for undefined char). None Hebrew font char appear. Furthermore, as already experienced in the past, if I export only the fourth page the table is perfecly exported... En error drift or similar trouble?

- the issue test document exports are bad in different area with respect to the same 3.1.0.2 ones. I attach them to this issue just now.

Hope that help.

Carlo

[Carlo-strata (carlo-strata)]

Created an attachment (id=294062)
Export of the issue's original file (64 bit OOo 3.1.0.4, pdf only, good)

[Carlo-strata (carlo-strata)]

Created an attachment (id=294063)
Export of the issue's original file (64 bit OOo 3.1.0.4, pdf/A-1a, bad)

[Carlo-strata (carlo-strata)]

No different behaviours with new 3.1.0.5 x86-64 release on

http://download.opensuse.org/repositories/OpenOffice.org:/UNSTABLE/openSUSE_11.1/

Exported pdf are similar to 3.1.0.4 ones.
I change status to Assigned and version to OpenOffice.org 3.1 with the hope to obtain more interest, attention to this problem.

May Gentoo people, being experienced to parameterize code and compilation on many (!) different platforms, help us a lot?!!!

Carlo

[Carlo-strata (carlo-strata)]

Yesterday I updated to 3.1.0.98.1 OOo build from this repo:
http://download.opensuse.org/repositories/OpenOffice.org:/UNSTABLE/openSUSE_11.1/

I test it again both with this issue's test document and my one (a writer document with less than 10 calc table inserted inside it that seems to issue one in the mean of a writer document with some object inserted).

In both cases I got (on my x84-64 platform):

- pdf only exports are bad (some hebrew font charaters instead of arabic ones), but read both on linux (Okular Version 0.8.80 on KDE 4.2.90, GhostView 1.5, my evince 2.27.1 since a month ago refuse to read pdf at all, "PDF Document (application/pdf) not supported"...) and on Windows Vista Home Premium 64 bit on Abobe Acrobat Reader 9.1.2 (32 bit);

- pdf/A-1a exports are fine (!), but read only on linux (Okular Version 0.8.80 on KDE 4.2.90); on Windows Vista Home Premium 64 bit on Abobe Acrobat Reader 9.1.2 (32 bit) I get the usual message that complains about an invalid color space.

During lasts releases I get the best result on x86-64 platform respectively for:

- pdf only exports from release 3.1.0.4 *appear to be perfect* and they read well on all test viewers and platforms (linux and Windows);

- pdf/A-1a exports from release 3.1.0.98.1 *appear to be perfect* and they read well only on linux test viewers and platforms (linux and Windows); on Windows Vista Home Premium 64 bit on Abobe Acrobat Reader 9.1.2 (32 bit) I get the usual message that complains about an invalid color space.

After this post will follow last two updated exports (pdf only and pdf/A-1a).

Hope that help,

Carlo

[Carlo-strata (carlo-strata)]

Created an attachment (id=298923)
Export of the issue's original file (64 bit OOo 3.1.0.98.1, pdf/A-1a, appear perfect but invalid color space on Acrobat on Windows)

[Carlo-strata (carlo-strata)]

Created an attachment (id=298924)
Export of the issue's original file (64 bit OOo 3.1.0.98.1, pdf only, bad)

[Carlo-strata (carlo-strata)]

3.1.0.5 and 3.1.0.6 exports (never submitted, but stored on my pc so that you can ask for them if needed) have been always worse and never appear perfect.

Carlo

[Carlo-strata (carlo-strata)]

3.1.0.99.1 exports (pdf/A-1a and normal pdf) seem to be perfect (no more Hebrew chars!) and open in Evince (2.27.4) (updated OpenSuSE 11.1, x86-64, 2.6.29.6).

So it happens in Windows, but only NON pdf/A-1a version opens while the pdf/A-1a export still raise the message "Invalid color space" in Acrobat Reader 9.1.2 (win32 version).

I will next attach the exported pdf files.

We are going to close this issue... ;-)

Carlo

[Carlo-strata (carlo-strata)]

Created an attachment (id=307758)
Export of the issue's original file (64 bit OOo 3.1.0.99.1, pdf only, appear perfect)

[Carlo-strata (carlo-strata)]

Created an attachment (id=307759)
Export of the issue's original file (64 bit OOo 3.1.0.99.1, pdf/A-1a, appear perfect in linux but invalid color space on Acrobat on Windows)

[Carlo-strata (carlo-strata)]

About "Invalid color space" on 64 bit platform export there already is an opened issue 467181 (https://bugzilla.novell.com/show_bug.cgi?id=467181).

So that, in my opinion, this issue could be closed! After some other tests, perhaps. My other own documents whose exports previous broken, now are fine but in the pdf/A-1a version still yield the "Invalid color space" message.

So that we can only go on in the associated issue (467181).

[Kendy (kendy)]

Carlo: Thank you a lot for your testing! Unfortunately I am not sure what exactly caused that the issue is fixed now :-( Petr, do you have an idea, please? Did you see a commit that could be related to this?

[Pmladek (pmladek)]

I am not aware about any related fix on ooo-build. I wonder if it might be related to an upstream fix.

For example, http://www.openoffice.org/issues/show_bug.cgi?id=102378 fixes a recent regression in the PDF export code. It seems that the code handling fonts is also shared with the printing functionality, ...

[RGB (ricardo-berlasso)]

I have the same problem: OOo 3.1, Novell build from the "ooo stable" repo change some number to another alphabet. Same file, same system but with Sun build work without problems.
I'm using a 64 bits system with openSUSE 11.1

[Carlo-strata (carlo-strata)]

It seems that the problem has been finally fixed in the vanilla trunk:
http://www.openoffice.org/issues/show_bug.cgi?id=106523

Someone may check if all the problems discussed in the current issue are fixed by the reported vanilla one?

Have a nice day,

Carlo

[RGB (ricardo-berlasso)]

@ Carlo Strata: I think the linked report is for another issue (problems with color space in exported pdf). This report is about characters being wrongly replaced on pdf export, and only affect Novell build.

[Carlo-strata (carlo-strata)]

But are you truly sure that the reported vanilla fix (C type related) doesn't fix this issue too??? This was and is my hypothesis but I can't check it at the moment.

And you, could you check it?

[RGB (ricardo-berlasso)]

As I said before, vanilla OOo do not show the problem. Only way to test if this fix the problem is to have a Novell build based on that vanilla build, and I don't have access to it now. Correct me if I'm wrong, but I think the "unstable" OOo branch for Novell build is based on OOO320_mX (X = 4 now) while the linked issue is solved for OOo 3.3, that is OOO300_mY with Y > 60

[RGB (ricardo-berlasso)]

It seems the problem is fixed with OOo 3.2 from "stable" repo. At least, I cannot reproduce it with same documents that gave problems on previous versions.

[Pmladek (pmladek)]

Thanks a lot for the feedback. I am closing this bug as fixed according to the comment #42.

[Pmladek (pmladek)]

.