Bug 59278 - EDITING: Missing dot when exporting PDF (regression)
Summary: EDITING: Missing dot when exporting PDF (regression)
Status: RESOLVED WONTFIX
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.0.0.1 rc
Hardware: Other Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: BSA
Keywords: regression
Depends on:
Blocks:
 
Reported: 2013-01-12 12:18 UTC by webofht-libreofficebugs002
Modified: 2013-01-25 15:49 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Screenshot comparing different PDF files of the same document (78.32 KB, image/png)
2013-01-12 12:18 UTC, webofht-libreofficebugs002
Details
Screenshot; 3.6.4.3 compared to 4.0 RC1; Mac OSX 10.8.2 (149.99 KB, image/png)
2013-01-14 18:19 UTC, Jorendc
Details
Just page 5 of the document in the PDF format by LibreOffice 3.6.4 (41.82 KB, application/pdf)
2013-01-15 15:30 UTC, webofht-libreofficebugs002
Details
Just page 5 of the document in the PDF format by LibreOffice 4.0.0.1 (41.82 KB, application/pdf)
2013-01-15 15:32 UTC, webofht-libreofficebugs002
Details
PDF of LO 4.0 and LO 3.6 PDF/A1 exports (19.20 KB, application/pdf)
2013-01-18 06:30 UTC, NoOp
Details
Compare the lines in LibreOffice (14.46 KB, application/vnd.oasis.opendocument.text)
2013-01-19 14:42 UTC, webofht-libreofficebugs002
Details

Note You need to log in before you can comment on or make changes to this bug.
Description webofht-libreofficebugs002 2013-01-12 12:18:28 UTC
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
Comment 1 Jorendc 2013-01-14 18:19:55 UTC
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).
Comment 2 Joel Madero 2013-01-14 21:15:50 UTC
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
Comment 3 webofht-libreofficebugs002 2013-01-15 15:30:50 UTC
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 (?).
Comment 4 webofht-libreofficebugs002 2013-01-15 15:32:30 UTC
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)
Comment 5 NoOp 2013-01-18 06:30:59 UTC
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.
Comment 6 webofht-libreofficebugs002 2013-01-19 14:42:37 UTC
Created attachment 73291 [details]
Compare the lines in LibreOffice

I agree with  NoOp.

I still get the difference.
Comment 7 Michael Stahl (allotropia) 2013-01-24 10:59:28 UTC
 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.
Comment 8 Caolán McNamara 2013-01-25 15:49:50 UTC
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.