Created attachment 50455 [details] Test kit with sample document and export result This problem has been found by Carlo Strata during research for "Bug 32849 - PDF: White table borders look grey" (what has other roots). The effect is that the top border disappears / reappears for various zoom levels in the exported PDF document. I see that with "LibreOffice 3.4.3 RC1 - WIN7 Home Premium (64bit) German UI [OOO340m1 (Build:301)]", 64 bit AMD Phenom II X4 955 Processor 3.2 GHz, 4GB RAM, Graphic Card: NVIDIA GeForce GT 430 For tests you can additionally use attachments by Carlo Strata from Bug 32849. Steps to reproduce: Create sampel document: 1. New Writer Document 2. Soe times <Enter> 3. New first table using Table icon + dragging 2x1 Table at the top of the document 4. New second table, created like the first one, with 1 paragraph difference 2 Additional similar tables 2 rows, 3 rows each with 1 paragraph distance 5. Save 6. Export to PDF (Lossless) 6. Open sample.PDF with AR X Expected: Table always looks like in LibO Actual: Top table border (only first table) disappears for particular zoom levels My results for various zooms (only table numbers where top border missing listed: 100% ok 103% (page width) ok 125% ok 150% 1 (First table top border missing) 200% 2 300% 1 400% 1,2 500% 1, 600% 1,2 800% 1,2 1200% 1,2 1600% 1,2 . . I never saw disappearing lines in tables with more than 1 row. I never saw other lines disappear than top. Problem also appears when measuring unit is pt when I create table. I believe part of the problem is that the border width of the tables is wrong. If you select all table, modify all borders ->0,5pt and than with down arrow at the value pane for width back to 0,25 pt, you will see that the line will become more thick (the same will happen if you change color to grey) and the effect will disappear. Please also compare border width with diagonal 0,25 pt line. Related to "Bug 33629 - Table top and bottom borders disappear then reappear after clicking inside the table"? NEW / OS=All due to various confirmations in Bug 32849 @Cédric: I assign to you because main problem seems to be the wrong table border for new tables with default border width. Please feel free to reassign (or reset Assignee to default) if it’s not your area. Please set Status to ASSIGNED if you accept this Bug.
Also a problem with OOo 3.4 (WIN), but not with OOo 3.1.1 (WIN)
I have said in Bug 32849 and in my emails that it is a long time ago bug... ;-) I would have to point out it since the first time I suspected for it (in my invoices' header!!!). Next time I will do it. :-)
I also tried with the latest OOo released installable build: OOo-dev 3.4.0 DEV300m106 (Build:9582) installed from the installer named: OOo-Dev_DEV300m106_Win_x86_install_en-US.exe that I have downloaded from here: http://download.openoffice.org/next/other.html I get the same behavior: so that this is also an Apache OOo (AOOo) not fixed bug. I try this because LibreOffice is OOo340m101 aligned and Rainer didn't say what exactly OOo340 version he have tested on/by (OOo340 beta1 or m106 or...). - Installed on Windows Vista, SP2, 64 bit, ita guied; - on my Acer Aspire 8920G, BIOS 1.16, 4Gbyte RAM, nVidia GeForce 9500M GS 512 Mbyte dedicated RAM, nVidia driver version 7.15.11.7626 (win64); - pdf viewed with Adobe Acrobat Reader 10.1.0, for Windows, 32 bit.
*** Bug 42613 has been marked as a duplicate of this bug. ***
Also printing might be affected as "Bug 42613 - PRINTING TABLE: top border of first row missing" seems to indicate, but that one also might have completely different roots.
This might be related to bug 36742.
I confirm that on LibreOffice 3.4.5 RC2, linux, x86-64, vanilla, installed on linux, OpenSuSE 12.1 (yes I have updated my notebook!), x86-64, kernel 3.1.0-1.2-desktop, Ita GUIed the problem is still present. :-( Verified on: - Evince 3.2.1 with poppler/cairo library (0.18.0); - Okular Version 0.13.2, PDF Backend Version 0.4, KDE 4.7.2 "release 5"; - Acrobat 10.1.1 on Windows Vista x86-64, SP2, updated, Ita GUIed. Any news about this very tedious bug? Have I to put it in the Bug 35673 "LibreOffice 3.4 most annoying bugs"? What do you think about? I think this bug mines LibreOffice PDF's quality... All PDF with tables are potentially corrupted by this bug. Carlo
Hi Carlo. would you like taking a look to this bug: https://bugs.freedesktop.org/show_bug.cgi?id=45078 do you think we're talking about the same issue or not? regarding your test kit .pdf file, I always see a missing upper border at any zoom factor I tried on Acrobat 8 (either shrinking or enlarging), and I never see that border reappearing. I have the same behaviour with my test .pdf file (see bug 45078 attachments) created in LibO 3.4.5
(In reply to comment #8) > Hi Carlo. > would you like taking a look to this bug: > https://bugs.freedesktop.org/show_bug.cgi?id=45078 > do you think we're talking about the same issue or not? > > regarding your test kit .pdf file, I always see a missing upper border at any > zoom factor I tried on Acrobat 8 (either shrinking or enlarging), and I never > see that border reappearing. > > I have the same behaviour with my test .pdf file (see bug 45078 attachments) > created in LibO 3.4.5 Hi Tommy, yes it's the same! And it's very annoying since to much time! I think that this bug (bug 40289), bug 36742 and yours (bug 45078) are the same one. I just test them with LibreOffice 3.5.0 beta3, win32 build, on my Windows Vista 64 bit, SP2, updated, ita GUIed and I obtained the same result: the bug is still here. Now I try with 3.5.0 RC1, I posti here test results and then I add them to Most Annoying 3.4 and 3.5 ones. I think they may hide a bad table width initialization and tick and color management. This affect quality and people LibreOffice quality ideas. Tables and default table width are too often used to yield many document and their exported PDFs so that people may easily decide because the border bug that LibreOffice is still too young to be adopted and so they may decide to unistall it putting all our efforts trough the window! It's a big pity!
I just test them with LibreOffice 3.5.0 rc1, win32 build, on my Windows Vista 64 bit, SP2, updated, ita GUIed and I obtained the same result: the bug is still here. I already have put them to "3.4 and 3.5 most annoying bugs" bugs. ;-) We are all here to help close this multiform sole and single bug! Have a nice evening, Carlo
thanks Carlo. I will later label Bug 45078 as duplicate of this one. moreover I'm wondering if the "zoom depending disappear/reappear" issue and the "always missing upper border" are truly LibO bugs or rather bugs of PDF-viewers If you download again my test files from Bug 45078 there's something weird about zoom levels and upper border visibility, depending on which PDF-viewer do you use. ---------------------------------------- 3.3.4 .pdf opened with Acrobat Reader 8 - upper border visible till zoom 200% - disappears at zoom 300% and higher ---------------------------------------- 3.3.4 .pdf opened with Foxit Reader 2.2 - upper border visible till 500% - disappears at 600% and higher ---------------------------------------- 3.4.5 .pdf opened with Acrobat Reader 8 - upper border always missing at any zoom level - never reappears ---------------------------------------- 3.4.5 .pdf opened with Foxit Reader 2.2 - upper border visible till 500% - disappears at 600% and higher ---------------------------------------- so it seems that the "disappear/reappear" behaviour is present with Foxit Reader 2.2 using both the 3.3.4 and 3.4.5 files and with Acrobat Reader 8 using just the 3.3.4 file while the "always missing border" only affects Acrobat 8 and the 3.4.5 file
*** Bug 45078 has been marked as a duplicate of this bug. ***
Hi Tommy, I think that pdf table borders are bad defined from a probably bad odf table border. Because of this each pdf viewer (on Windows I personally use Adobe Acrobat 10.1.2, win32 build) display them (borders) at his best and depending on its rendering code. If you print the 1x1 table you always / often don't see the upper border. This seems to be an old regression since OOo 3.1.1... I think it's very important to be fixed becaused may hide a document generation derive on table definition, initialization or so on... I hope that LibreOffice 3.4.6 and LibreOffice 3.5.0 (= rc3) both have this bug fixed and that fix will improve LibreOffice document quality and people LibreOffice quality idea. ;-)
(In reply to comment #12) > *** Bug 45078 has been marked as a duplicate of this bug. *** Are you sure that is correct to mark that bug as *resolved* (!!!) duplicate rather than (and simply) *closed* duplicate. That (and this) bug isn't resolved and seems to be far away to be fixed!!! So I don't want that someone think it's fixed. ;-)
I think the bug 39415 is very interesting. When I read it, I immediately ask myself if that bug is related on this one and similar few others. My idea is: are the table border badly managed (by an altered code) on internal LibreOffice data and this cause all the bug mentioned here? In the generated pdfs I frequently note identically defined borders that are differently displayed both in width and in colors... I'm thinking if this is due to data loss in internal (LibreOffice) table data structures... I mean badly initialized and updated data... What do you think about this? I'm only a visionary? ;-)
still reproducible in 3.5.1 on Vista 64bit as I told before, the visibility of the table upper border varies according to the zoom level and the pdf reading software you are using. --------------------- Foxit Reader 2.2 --------------------- from 8.33% to 400% --> border visible from 600% to 1600% --> border invisible --------------------- Adobe Acrobat --------------------- border invisible at any zoom level so the border, is somewhere exported in the file (Foxit Reader shows it at some zoom level) but fails to be rendered correctly in a consistent way
The line width in the ODT document are given as 0.05 pt. 1 pt is roughly 1/72 in, or 1 pixel on a screen device w/72 dpi. 0.05 pt are 1/1440in, or 0.00069 in, or 0.044mm. Give a printer resolution of 600 dpi, that would be a line of about 1 pixel width. The PDF specification defines a user space and all sizes are given in user space units. It's possible to define sizes of 0 user space units, which should transform to the smallest unit in the device space, that is, 1 pixel, be it on screen or on paper. But given the fact that the device is rasterized, the 1 pixel wide line might fall between two raster lines and the implementation is then free to omit the line, AFAIK. It's explicitly recommended to not use 0 user space units (PDF specification 4.3.2 Details of Graphics State Parameters, Line Width). As far as I can see, the 0.05pt are output to the PDF as a line of zero user space units width. The 0.25 pt wide line is emitted as that, 0.25 user space units (because user space units are roughly equal to a point or 1/72 in). Unfortunately, the writer UI rounds down any value below 0.25pt to 0.05 pt, which in turn get rounded down to zero user space units in our pdfwriter impl. I'm trying to verify this. I wonder what the solution should be here: probably best would be to prevent non-zero pt units to be rounded down to zero in pdf export, and enforcing a minimum line width of 0.1 user space units, which should hopefully prevent most readers from omitting the lines.
@Peter Jentsch mmmhhh.... interesting post!!! it makes sense... I hope it will help the devs
Writer UI doesn't round down border width: it only appears to do so when modifying border width within cell ranges containing multiple border width. Also, hacking void PDFWriterImpl::PDFPage::appendMappedLength( double fLength, OStringBuffer& rBuffer, bool bVertical, sal_Int32* pOutLength, sal_Int32 nPrecision ) (in pdfwriter_impl.cxx) to round up lengths below 0.1 to 0.1 doesn't seem to help, though setting the line widths for all table borders to at least 0.15 pt does. 0.25 or roughly 0.1mm seems to be the minimum line width mandated by print shops by the way (see http://www.utsch-media-service.de/download/Druckspezifikationen.pdf and http://www.persiehl.de/de/wp-content/uploads/Digital_Guide.pdf, both only in german unfortunately) as an example, so maybe it wouldn't be to bad to impose a similar limit on the minimum line width in writer or all of libo. Apparently PDF renderers (Mac OS X Preview and Adobe Reader 10 tested) seem to be able to handle line widths above 0.15pt without omitting lines. Internally, we're calculating with 1/20th of a point (or 0.05 pt, like in the sample document), and while this might be a good unit for calculations it might not be an optimal minimum size. Strictly speaking, this is not a bug: you just shouldn't use line width of below 0.15pt in your documents, because both printers and screen viewers might have problems displaying that. I would be great to have something like preflight for that, at tool that checks if your document violates some restrictions of the intended output media.
I just read the initial comment """ ... main problem seems to be the wrong table border for new tables with default border width. """ 0.15pt might be a good default, also see http://www.prepressure.com/pdf/basics/preflight IANAPrinter, but google tells me between 0.2 and 0.125 is seen as the minimum size for printing.
3.4 lifecycle is terminated, so only remaining “Bug 37361 LibreOffice 3.5 most annoying bugs”
(In reply to comment #17) > 0.05 pt are 1/1440in, or 0.00069 in, or 0.044mm. > > Give a printer resolution of 600 dpi, that would be a line of about 1 pixel > width. > So, at a resolution of 1440 dpi that's 1 pixel :-P
still here in LibO 3.5.3 and LibO 3.6 dev (Build ID: 52348aa)
tbehrens, what do you think of the approach suggested by Peter in comment #19 and comment #20 to round up line widths in PDF export to something like 0.15 pt? seems sensible to me.
(In reply to comment #24) > tbehrens, what do you think of the approach suggested by > Peter in comment #19 and comment #20 to round up line > widths in PDF export to something like 0.15 pt? > seems sensible to me. > Grmbll, yeah, if pdf is really not mandating 0 to mean "1 device pixel", then this is probably a sensible way forward. It still assumes a lot about the pdf device model, though.
No longer reproducible with "LibreOffice 3.6.3.1” English UI/ German Locale [Build-ID: f8fce0b] on German WIN7 Home Premium (64bit). I did a PDF export from .odt in test kit and compared in various zooms with .pdf from test kit. Original .pdf from test kit still shows the missing border line problem with AR 10.1.4, the new pdf from 3.6.3 does no longer show that problem in AR. so WFM, unknown where that really got fixed.
@Reiner would you please upload here the 3.6.3-generated test .pdf file? I'd like to test it with other pdf readers since (see comment 16) visibility of thin table border varied among different softwares
Created attachment 68548 [details] Export Result from LibO 3.6.3.1 @tommy27: Good idea, here you see the result
@Reiner I think that most of the issue depends on the used PDF reader, not on LibreOffice. I tested the new file on my system (Vista 64bit) with different softwares: Acrobat Reader 8 --> thin table top border invisible at any zoom level Foxit Reader Portable 2.2 --> always visible Foxit Reader Portable 5.4.3 --> always visible while you said that Adobe Acrobat Reader 10 behaves correctly. so, is this really a LibO 3.6.2 bug or rather an AAR 8 bug?
according to my previous comment it seems that this is a rendering issue of different PDF readers, not an issue of LibO PDF output. changing status to NOTOURBUG
Tested https://bugs.freedesktop.org/attachment.cgi?id=67259 on LO 3.6.5.2 some lines (41, 61): Acrobat Reader 10 --> always visible PDF-Xchange Viewer 2.5. b207 --> thin table top border invisible at any zoom level Foxit Reader Portable 4.2 --> thin table top border invisible Foxit Reader Portable 5.1 --> thin table top border invisible Foxit Reader Portable 5.4.5 --> thin table top border invisible (different from tommy27) from tommy27: Acrobat Reader 8 --> thin table top border invisible at any zoom level Foxit Reader Portable 2.2 --> always visible Foxit Reader Portable 5.4.3 --> always visible Anyway, it depends on PDF reader.