Apache OpenOffice (AOO) Bugzilla – Issue 52885
JPEG-compressing PDF export shows tif as negatives
Last modified: 2005-08-08 10:44:40 UTC
I checked with 2.0 (1.9.m122) German version WIN XP: [680m122(Build8941)] and found the PDF-Export completely messed up, pls. see attached screenshots comparing results of 680m113 (ok) and 680m122 (messed up). This issue may be a regression of issue 47395 Something concerning the DRAW document from which I exported: I use the document to add changes and additions to an old circuit diagram. For that I scanned the old diagram and inserted the .tif drawings by link into pages of my draw document to Layer "Layout". That layer will be locked for further work. All my changes will be in a new Layer "Änderungen" (= "changes"), for example texts (as "Modul:01" and "-4N2"). The missing Text "$22: 000" ist a text field like "Modul:01" Many other elements of the drawing are missing in the PDF export, sometimes I even see a border where the element should have been, sometimes not. Those 2missing" Elements (at least the text Elemnts) seem to be in the PDF (I can find them with PDF text search", but they are invisible, because black as the inverse .tif area. "Modul:01" is visible, because it is written on a white background. That all seems to say that this really is a regression from issue issue 47395, but I am a little worried concerning the small PDF size even if I try "uncompressed", but may be that that is caused by the many "black line on black background", what must not be shown in the PDF grafic? If you believe it might eb useful, I can supply a drawing with only few pages to demonstrate the most important problems. Please decide whether this issue should remain or be closed DUP.
Created attachment 28495 [details] screenshot showing the effect
T believe that it is related to issue 47395 because of comments in issue 52851
It's nothing with the DRAQ-document itself, PDF export from the same document with 680m113 works without problems.
It's not a regression since the fix for issue 47395 has not been integrated. If that tiff is 1 bit and you used "lossless compression" this seems like a duplicate to 47395.
The effect is always visible, with "looseless compression" and also with "jpeg compression". Does "tiff is 1 bit" mean "black / white"? Yes, the tifs are "monochrome".
I checked with 2.0 (1.9.m118) English version WIN XP: [680m118(Build8936)] and also saw the problem (m113 was ok!).
As long as the graphic is 1 bit monochrome it does not matter what compression you use (1bit images cannot be JPEG compressed); sorry i was unclear about that. Just one question remains: is it the same TIFF file that worked in 113 and does not in 118 ? Or might two different TIFF files in use where the meaning of 1/0 for black and white pixels is simply reversed ?
I did all my tests with the same DRAW document containing the all the same tiff- images.
Am a little sluggish today, but I begin to understand. In 680m113 we had the same problem, but it occured only for "looseless compression". Later versions (starting for me with 680m118) now show the same bug also for "jpeg-compression".
Amended summary to current standard of knowledge
Well, the 1 bit tiff problem doesn't happen anymore in CWS vcl42. For verification that this issue is actually fixed with issue 47395 i'd like to try test one of your sample documents. Could you attach one ?
Created attachment 28536 [details] Testkit for check with CWS vcl42
'testkit.zip' contains a drawing with some (linked) tif-files. With that example I see the "negative-problem" with 2.0 (1.9.m122) German version WIN XP: [680m122(Build8941)] in looseless _and_ JPEG- compression.
Ok, this is reproducible in m122 but not in CWS vcl42 (based on m122) anymore. That makes it a duplicate to issue 47395 after all. *** This issue has been marked as a duplicate of 47395 ***
closing duplicate