Bug 45001 - FILEOPEN particular .PDF shows some elements at wrong position
Summary: FILEOPEN particular .PDF shows some elements at wrong position
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Draw (show other bugs)
(earliest affected)
Inherited From OOo
Hardware: x86 (IA32) All
: medium normal
Assignee: vvort
Whiteboard: target:4.3.0
Depends on:
Reported: 2012-01-20 10:51 UTC by mathog
Modified: 2014-04-08 14:56 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:

Example PDF, imports poorly (7.01 KB, application/pdf)
2012-01-20 10:51 UTC, mathog
Screen shot of 3.5.0rc1, shows defects on import (9.01 KB, image/png)
2012-01-20 10:52 UTC, mathog
Original Inkscape drawing (7.85 KB, image/svg+xml)
2012-01-20 10:53 UTC, mathog
screenshot in, show offset element problem (6.67 KB, image/png)
2012-05-11 21:36 UTC, Korrawit Pruegsanusak
E at 0,90,180,270 at corners of a rectangle. (6.24 KB, application/pdf)
2012-10-03 16:40 UTC, mathog
E at 0,80,180,270, source SVG (4.69 KB, image/svg+xml)
2012-10-03 16:47 UTC, mathog

Note You need to log in before you can comment on or make changes to this bug.
Description mathog 2012-01-20 10:51:32 UTC
Created attachment 55846 [details]
Example PDF, imports poorly

The simple example PDF file has THREE faults on import into LODraw.  Original consists of two green circles, each with a "+" character in the center, and one group of lines (a dashed line).  On import these faults occur:

1.  The "+" characters are offset from the corresponding circles.
2.  The dashed line is offset a different amount from its original position (as determined by its position with respect to the two green circles).
3.  The "+" characters are duplicated.

All 3 of these issues were present in 3.5.0b2.  The first two were also present in 3.4.4 release.  The first two are rare problems, these were the only two occurrences from an original drawing of several hundred elements.  

The third one, the character duplication, is a major problem.  It was seen in numerous locations in the original.  It happens so frequently that cleaning up the imported PDF becomes a major challenge.

Offsets of objects, like the dashed lines here, have only been seen on graphic objects which were rotated at some point in the original drawing (in Inkscape).  Rotation is not sufficient to cause the offset: the majority of such objects are not offset, but it may be necessary.
Comment 1 mathog 2012-01-20 10:52:13 UTC
Created attachment 55847 [details]
Screen shot of 3.5.0rc1, shows defects on import
Comment 2 mathog 2012-01-20 10:53:14 UTC
Created attachment 55848 [details]
Original Inkscape drawing
Comment 3 tester8 2012-01-20 14:24:42 UTC
Reproduced with

LOdev 3.5.0rc1
Ubuntu 10.04.3 x86
Linux 2.6.32-37-generic Russian UI
Comment 4 Korrawit Pruegsanusak 2012-05-11 21:35:04 UTC
Duplicated characters was fixed in bug 45848, so reduce this ticket to only one problem -- offset elements
Comment 5 Korrawit Pruegsanusak 2012-05-11 21:36:11 UTC
Created attachment 61471 [details]
screenshot in, show offset element problem
Comment 6 Korrawit Pruegsanusak 2012-05-11 21:53:58 UTC
offset element problem is reproducible in LibO 3.3.0 Windows XP, and reporter said in comment 0 that

> The first two were also present in 3.4.4 release.

So, change version field to the earliest version reproducible.
Comment 7 Rainer Bielefeld Retired 2012-10-03 06:30:33 UTC
Still  [Reproducible] with parallel installation of Master "LOdev   -  ENGLISH UI / German Locale  [Build ID: bc63efc]"  {tinderbox: @6, pull time 2012-09-24 21:00:28} on German WIN7 Home Premium (64bit)
(PDF Import Extension 1.0.6)

AOOo 3.4.1 with Oracle PDF Import Extension has the same problems, so inherited from OOo!

All OS due to Comment 3

May be we nave 3 different problems here?

When PDF will be opened with LibO:
1) The "+" shown at wrong position (completely wrong horizonal and a little shifted vertically) are rotated text elements, what are shifted the same distance from their original position. Might be related to "Bug 44710 - FILEOPEN PDF: Rotated texts at wrong position and scrambled"?

2) The dashed line will be shown as several separate lines, and the horizontal/vertical  mismatch is different to the mismatch of the "+"

3) The rotation of the "+" is a little wrong, should be 270°, is 269.24°

currently we have only 1 document in the world showing these distortions, that's not a major problem for LibO. Can you contribute info that that we have a more general problem here like "All rotated tests .... always ...."?

Please split into separate bugs If you see that 1 ... 3 indeed are separate bugs.
Please set Status to ASSIGNED and add yourself to "Assigned To" if you accept this Bug or forward the Bug if it's not your turf
Comment 8 mathog 2012-10-03 16:40:45 UTC
Created attachment 68048 [details]
E at 0,90,180,270 at corners of a rectangle.
Comment 9 mathog 2012-10-03 16:47:20 UTC
Generalization?  OK...

  All rotated text in PDFs created by Inkscape are placed incorrectly
  when opened in LODraw (  

That isn't to say that PDFs made in other ways might not also have this problem, only that I have not tested that.  

The rotE.pdf just attached actually shows that even the unrotated character is slightly offset.  In each case the "E" was manually aligned so that corner of the rectangle was at the intersection of the vertical and center bars of the E, so it is relatively easy to see this. 

None of these offsets appear when rotE.pdf is viewed in PDF XChange Viewer.

The character duplication issue seems to have been resolved.

I do see a bug in the PDF generation from Inkscape - it converted "Arial" in the source SVG to "Arial Narrow Bold" in the PDF.
Comment 10 mathog 2012-10-03 16:47:54 UTC
Created attachment 68049 [details]
E at 0,80,180,270, source SVG
Comment 11 mathog 2012-10-03 17:00:49 UTC
Correction, that was Arial Bold to Arial Bold Italic, see Inkscape bug 200899

Comment 12 Rainer Bielefeld Retired 2012-10-03 17:19:37 UTC
Comment on attachment 55846 [details]
Example PDF, imports poorly

More specific sample document available
Comment 13 Rainer Bielefeld Retired 2012-10-03 17:20:05 UTC
Comment on attachment 55848 [details]
Original Inkscape drawing

More specific sample document available
Comment 14 Rainer Bielefeld Retired 2012-10-03 17:22:05 UTC
Comment on attachment 61471 [details]
screenshot in, show offset element problem

More specific sample document available
Comment 15 Rainer Bielefeld Retired 2012-10-03 17:35:36 UTC
Great Sample!
Do I understand <https://bugs.launchpad.net/inkscape/+bug/200899> correctly? There is a Bug in Incsape PDF export? So LibO should be a little more liberal and ignore that little problem and show rotated text correctly like AR?

It seems the problem with "----" in attachment 55846 [details] is different? If yes, please submit a new Bug (you can refer to attachment here due to <https://wiki.documentfoundation.org/QA-FAQ#How_to_use_attached_sample_documents_for_multiple_Bug_Reports>) and add me to CC!
Comment 16 mathog 2012-10-03 18:24:47 UTC
Inkscape bug https://bugs.launchpad.net/inkscape/+bug/200899 turned out to be irrelevant.  It looked like Inkscape was exporting the wrong font-weight, but it turned out that for some SVG files Inkscape was actually displaying the wrong font-weight https://bugs.launchpad.net/inkscape/+bug/1061128.  Inkscape was correctly sending its internal value to the PDF file correctly.

The --- issue is different but I just don't have time to work on that now.  One last observation though - if one imports the original PDF (now in bug #55846) into Inkscape, save as PDF, then open in LODraw, then the --- moves as reported previously.  If instead one imports the PDF into Inkscape, ungroups everything (this is the one thing that is done differently), then save as PDF, then open that PDF in LODraw, then the --- stays where it should be.  Both of these PDF's look the same in a PDF viewer. So it looks like the --- problem is related to how LOWdraw is handling rotations or groupings from PDF files.
Comment 17 vvort 2014-03-29 07:32:20 UTC
To fix "E rotation" problem, we need mirroring support for text (or, generally, properly working scale case in draw:transform parameter)
Comment 18 vvort 2014-04-08 05:56:06 UTC
Rotation by 180 degrees can be represented as mirroring by X and by Y and vice versa
This is used to hackfix "E rotation" problem
Patch is here:
Comment 19 Commit Notification 2014-04-08 14:51:45 UTC
Vort committed a patch related to this issue.
It has been pushed to "master":


fdo#45001 fdo#77105 PDF Import: rotated text fixes

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
Affected users are encouraged to test the fix and report feedback.