Apache OpenOffice (AOO) Bugzilla – Issue 122984
Faxes longer than one side wont' work (I guess wrong TIFF is created)
Last modified: 2017-05-20 10:35:44 UTC
On Version 3.2 we did not have any problems with faxing. With the version 3.4 the problems started. It was not possible to send a fax. Though we went back to Version 3.2 on all workstations and everything went fine again. Now I saw, that version 4 is out and on one workstation I tried the actual version..... same bug. But now I could find out a bit more: I think the problem is, that OpenOffice is not able to create appropriate more-sided TIFF's. When I fax a single sided document, it works fine. Only if the document has more than one side, there is a problem. Faxing a single sided document: in the Fax-Wizard I can open the TIFF and it shows the right content. The document is faxed the right way. Faxing a more-sided document: It is not possible to open the generated TIFF in the Fax-Wizard. Windows complains: It is not possible to open the Image, because the form is not recognized.... Faxing this document results in sending two empty sides. We fax over a SBS 2011 Fax-Server (the problems were aswell with an sbs 2000 Server). So I could not test a local fax-Modem. Since I guess that the generated TIFF is wrong, I am quite convinced, that the same problems occur aswell, when faxing with locally installed modems. If you test it out, be sure, to use more than one side. As I told, single sided faxes work, more sided, wont. Greetings Martin
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...
Not a bug per comment 6 Thank you Armin
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.