Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
Summary: | Faxes longer than one side wont' work (I guess wrong TIFF is created) | ||||||
---|---|---|---|---|---|---|---|
Product: | Writer | Reporter: | buebue <walkmeister> | ||||
Component: | printing | Assignee: | Armin Le Grand <Armin.Le.Grand> | ||||
Status: | CLOSED FIXED | QA Contact: | |||||
Severity: | Major | ||||||
Priority: | P3 | CC: | Armin.Le.Grand, elish, issues, michael.kairies, walkmeister | ||||
Version: | 4.0.0 | ||||||
Target Milestone: | 4.2.0 | ||||||
Hardware: | All | ||||||
OS: | Windows, all | ||||||
Issue Type: | DEFECT | Latest Confirmation in: | 4.0.1 | ||||
Developer Difficulty: | --- | ||||||
Attachments: |
|
Description
buebue
2013-08-08 16:55:57 UTC
Please specify steps to reproduce. (In reply to Edwin Sharp from comment #1) > Please specify steps to reproduce. Print a Document over a Fax-Printer: If the document is single-sided it works, if the document has more than one side it won't work. Can't personally reproduce due to no access to Fax-Printer. Hello, I can confirm this problem with multi-sided documents. I'm using OpenOffice v4.0.1 [AOO401m5(Build:9714) - Rev. 1524958 2013-09-20 11:40:29 (Fr, 20 Sep 2013)] on PC with MS Windows 7 Professional (64bit) and a faxprinter ("Microsoft Shared Fax Driver"). My steps to install the local faxprinter on Windows 7: open the "control panel" -> select "Programs and Features" -> "Turn Windows Features On or Off" -> expand "Print and Document Services" -> set the check mark by "Windows Fax and Scan" -> reboot A simple OO Writer Document which consists of 2 words on two pages (e.g. "hello <manual FormFeed> World!") produces a corrupt fax-preview. Greetings Michael Thank you Michael. Checked if AOO creates the TIFF itself (code in filter/source/graphicfilter/etiff/etiff.cxx), but it does not. Thus the conversion is in the OS, not on AOO side. Indeed from two pages on the created TIFF has an invalid format. It may be that the converter in the OS could create valid TIFFs when the created data from AOO changes, but at the end that converter does something wrong and is not under our control -> not an AOO error... Still taking a look at the print data we create. Checked for the diff between 2-page and 1-page TIFF, the 1st has no tags (while the 2nd has), so no width/height and other data will be read. Will check if page sizes are correct in our page printer... It looks as if we setup a PrintJob for every single page, this would explain the behaviour (still bad when external tools create invalid TIFFs). In Printer::SetPaperSizeUser the Paper (data type) is set to PAPER_USER in any case, but in the same method it is evtl. moved to another Paper in method ImplFindPaperFormatForUserSize. Because of that the next call to Printer::SetPaperSizeUser will think a new JobSetup is needed since the Paper created by ImplFindPaperFormatForUserSize != PAPER_USER. I have added for test purposes to compare Paper against PAPER_USER and the mapped Paper type (which can be computed using the paper size and ImplGetPaperFormat), this does no longer change the JobSetup and a two page Writer doc can be converted from the system to a two page tiff which can be opened. Caveats are: (a) The normal print also currently does a new JobSetup for every page which seems to be wrong but works; changing this would be a deeper change (b) The created MultiPage TIFF can be read by MS viewer and others, but not by our own TIFF importer. Already took a look, seems to be a problem with the last line decoding in 2D 1Bit mode... Reopening... Grepping, preparing patch Created attachment 82898 [details]
Less JobSetups, more tolerant TIFF import
With this patch a simple two-sided writer doc can be printed as fax on win, the TIFF can be opened in MS viewer. Second part is for being able to open that TIFF in AOO, too.
Providing as patch currently since I am not sure how much this might influence other print scenarios. Feel free to test this out.
Did some more checks, especially with printing. Works all well with applied patch. Very interesting is the behaviour with multiple page formats in one document, e.g. Writer. I created a test file with a landscape and a portrait page. Print works well, Fax creates again a non-readable TIFF (due to the fact that new JobSetups are needed here). Then I tried the same with MS Word 2010 and see, it's the *same* result, the TIFF for fax is unreadable. This proves that the fax TIFF creator cannot handle multiple print job setups correctly (all win7). Still, with the patch, multipage docs which keep the page format will create correct fax TIFFs and print looks good. Too dangerous for 4.1.0, but good for trunk. Preparing commit... "alg" committed SVN revision 1579210 into trunk: i122984 Avoid too many Print JobSetups, be more tolerant with last line TIFF ... Committed, done. |