Created attachment 72900 [details] Screenshot comparing different PDF files of the same document Problem description: A dot is missing in a PDF file generated by LibreOffice 4.0.0.1. However, in LibreOffice 3.6.4.3, the dot is present. This is a software regression. Steps to reproduce: 1. The operating system used is Linux debian 2.6.32-5-686 #1 SMP Sun Sep 23 09:49:36 UTC 2012 i686 GNU/Linux. 2. The LibreOffice versions involved are: - LibreOffice Version 3.6.4.3 (Build ID: 2ef5aff) (LO3.6.4) - LibreOffice Version 4.0.0.1 (Build ID: 527dba6f6e0cfbbc71bd6e7b88a52699bb48799) (LO4.0.0.1) 3. The document involved is: http://subversion.assembla.com/svn/FOUR/trunk/docs/Preliminary%20Report.odt 4. File -> Open -> (that document) 5. File -> Export as PDF -> PDF/A-1a -> Export 6. Use DiffPDF to compare the PDF files of the same document. 7. Copy and paste the text in a text editor to see the difference. 8. On page five of the PDF files, In LO3.6.4 FIGURE 1: SAMPLE MAZE (COURTESY OF W. D. BISHOP, LAB 4 SLIDES)................................................1 48 dots are present. In LO4.0.0.1 FIGURE 1: SAMPLE MAZE (COURTESY OF W. D. BISHOP, LAB 4 SLIDES)...............................................1 47 dots are present. Current behavior: A dot is missing in LO4.0.0.1. Expected behavior: The dot should be present in LO4.0.0.1. I am submitting the screenshot comparing the PDF files. Regards, C. H. D. Operating System: Debian Version: 4.0.0.1 rc Last worked in: 3.6.4.3 release
Created attachment 73016 [details] Screenshot; 3.6.4.3 compared to 4.0 RC1; Mac OSX 10.8.2 Can't reproduce that, both 47 dots (3.6.4.3 vs 4.0 RC1) using Mac OSX 10.8.2 ... But the dots aren't formatted that good (see attachment).
Does this have any real impact on the document? If not, I am prone to close it as WONTFIX as maybe 4.0 handles the pdf export better than 3.6 (why do you think 3.6 is better). Marking as NEEDINFO. If you have a reason to a) claim that this is a bug and not an improvement over 3.6 and b) will somehow impact yourself and others please mark it as NEW and I'll say it's confirmed as I do see a difference. Thanks for reporting
Created attachment 73099 [details] Just page 5 of the document in the PDF format by LibreOffice 3.6.4 I am submitting page 5 of the PDF file for further comments. I do not see any improvement (?) on Debian Linux. I do not know if this is the issue on Debian Linux only (?). I do not know if we should expect that much consistency in LibreOffice 4.0.0.1 and 3.6.4.3 (?).
Created attachment 73101 [details] Just page 5 of the document in the PDF format by LibreOffice 4.0.0.1 I am submitting page 5 of the PDF file for further comments. (LibreOffice 4.0.0.1 this time)
Created attachment 73231 [details] PDF of LO 4.0 and LO 3.6 PDF/A1 exports Perhaps this will help. The attached PDF Shows the comparison between LO 4.0 and LO 3.6. As reported, LO 4.0 produces 47 table dots/periods, LO 3.6 produces 48. To test I exported PDF/A-1a from each (no other PDF export options checked) and then copy & pasted the 'SLIDES)...............................................1' from each into LO.
Created attachment 73291 [details] Compare the lines in LibreOffice I agree with NoOp. I still get the difference.
15af925c254f27046427de70a59011e2ac3d6bdb..836822522a2e9f009c0870cbbcd48d45bbd3c622 this changed via this commit: commit f4d20a400b5c06959fd5a362a350bb4d9a6e4bd1 Author: Caolán McNamara <caolanm@redhat.com> Date: Sat Jul 14 21:21:15 2012 +0100 Resolves: fdo#31821 use icu layout whenever possible because icu knows all about otf so we don't have to, which makes things its problem and not ours. This is the default route for all "ctl" languages already so if we suffer performance issues here we should try and fix that before just reverting which probably results in some tiny change in the size of the text of the line. the index entry text is automatically generated anyway, and i don't think it really matters if there are 47 or 48 dots here, so i'm inclined to close this bug.
The width of the pair-kerned text before the ... in 4-0 is laid out to be 1/1440 of an inch wider than in 3-6, so there's space for one less "." in the rest of the line. Digging into this, I'm satisfied that, in this example at least, the positioning of text in the new layout is more correct than in the old layout. The old layout in 3-6 in vcl/generic/glyphs/gcach_layout.cxx looped through the glyphs using ints for the glyph widths, then called int nKernValue = rFont.GetGlyphKernValue( nOldGlyphId, nGlyphIndex ); between each pair of glyphs and applied that int amount of kerning to the width to get the next glyph position. So it was working in rounded/truncated int values of kerning values and glyph widths. The new layout of 4-0 works in floats and operates (well icu does this for us) with more accurate glyph widths and kerning values, and we only round the final positions of all the glyphs to int *after* the kerning is applied.