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.
Created attachment 55847 [details] Screen shot of 3.5.0rc1, shows defects on import
Created attachment 55848 [details] Original Inkscape drawing
Reproduced with LOdev 3.5.0rc1 e40af8c-10029e3-615e522-88673a2-727f724 Ubuntu 10.04.3 x86 Linux 2.6.32-37-generic Russian UI
Duplicated characters was fixed in bug 45848, so reduce this ticket to only one problem -- offset elements
Created attachment 61471 [details] screenshot in 3.5.3.2, show offset element problem
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.
Still [Reproducible] with parallel installation of Master "LOdev 3.7.0.0.alpha0+ - 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° @mathog: 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 ...."? @Thorsten: 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
Created attachment 68048 [details] E at 0,90,180,270 at corners of a rectangle.
Generalization? OK... All rotated text in PDFs created by Inkscape are placed incorrectly when opened in LODraw (3.6.1.2). 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.
Created attachment 68049 [details] E at 0,80,180,270, source SVG
Correction, that was Arial Bold to Arial Bold Italic, see Inkscape bug 200899 https://bugs.launchpad.net/inkscape/+bug/200899
Comment on attachment 55846 [details] Example PDF, imports poorly More specific sample document available
Comment on attachment 55848 [details] Original Inkscape drawing More specific sample document available
Comment on attachment 61471 [details] screenshot in 3.5.3.2, show offset element problem More specific sample document available
@mathog: 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!
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.
To fix "E rotation" problem, we need mirroring support for text (or, generally, properly working scale case in draw:transform parameter)
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: https://gerrit.libreoffice.org/8890
Vort committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=a20e145cf901f6589ca96e3a4a5ded413eb20907 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: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.