Issue 122984 - Faxes longer than one side wont' work (I guess wrong TIFF is created)
Summary: Faxes longer than one side wont' work (I guess wrong TIFF is created)
Alias: None
Product: Writer
Classification: Application
Component: printing (show other issues)
Version: 4.0.0
Hardware: All Windows, all
: P3 Major (vote)
Target Milestone: 4.2.0
Assignee: Armin Le Grand
QA Contact:
Depends on:
Reported: 2013-08-08 16:55 UTC by buebue
Modified: 2017-05-20 10:35 UTC (History)
5 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: 4.0.1
Developer Difficulty: ---

Less JobSetups, more tolerant TIFF import (3.58 KB, patch)
2014-03-18 15:11 UTC, Armin Le Grand
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this issue.
Description buebue 2013-08-08 16:55:57 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. 


Comment 1 Edwin Sharp 2013-08-08 19:31:29 UTC
Please specify steps to reproduce.
Comment 2 buebue 2013-08-08 20:35:06 UTC
(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.
Comment 3 Edwin Sharp 2013-08-14 05:42:43 UTC
Can't personally reproduce due to no access to Fax-Printer.
Comment 4 Michael 2014-03-15 21:29:40 UTC

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.

Comment 5 Edwin Sharp 2014-03-16 06:29:15 UTC
Thank you Michael.
Comment 6 Armin Le Grand 2014-03-18 11:51:47 UTC
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...
Comment 7 Edwin Sharp 2014-03-18 12:11:41 UTC
Not a bug per comment 6
Thank you Armin
Comment 8 Armin Le Grand 2014-03-18 12:29:09 UTC
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...
Comment 9 Armin Le Grand 2014-03-18 14:45:06 UTC
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...
Comment 10 Armin Le Grand 2014-03-18 15:07:51 UTC
Grepping, preparing patch
Comment 11 Armin Le Grand 2014-03-18 15:11:25 UTC
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.
Comment 12 Armin Le Grand 2014-03-19 12:27:02 UTC
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...
Comment 13 SVN Robot 2014-03-19 12:34:45 UTC
"alg" committed SVN revision 1579210 into trunk:
i122984 Avoid too many Print JobSetups, be more tolerant with last line TIFF ...
Comment 14 Armin Le Grand 2014-03-19 12:37:19 UTC
Committed, done.