Apache OpenOffice (AOO) Bugzilla – Issue 118542
Top and Bottom Margins are Merged when Printing
Last modified: 2016-04-15 16:37:04 UTC
I print a monthly report for myself and my brother every month concerning joint expenses on the house we own. I print it on a dot-matrix printer, a Panasonic KX-P1624. One of the peculiaritis of this printer is that, when using the tractor, paper positioned by the printer starts printing about 3/4" from the top of the page (manual positioning can change this, but is quite tedious). However, this is only true of the first page: subsequent pages can begin printing at the top of the page without manual positioning. This causes endless problems with most print programs: either the text has an extra top margin, or the text migrates because the print program believes the page to be shorter that it actually is. As might be imagined, OOo's ability to link styles is very helpful in this situation: the first page uses a style called "Letter Panasonic First Page". This pretends that the page is 10.25" high with no top margin and a 3/4" bottom margin. It also prints correctly: the actual page has a 3/4" margin at both top and bottom. This style is linked to the style "Letter Panasonic", which admits that the page is actually 11" and which specifies 3/4" margins at both top and bottom. This worked properly prior to OOo 3.3 -- OOo 3.2, for example, produced documents whose second and third pages had margins at both top and bottom -- but OOo 3.3 starts the text 1.5" from the top of the page and ends it at the very bottom. It is as if the margins are being merged and applied solely to the top of the page. I chose "major" because I regard this as a major embarassment. Of course, if it only affects dot matrix printers, then this may not be "major" from the viewpoint of users in general. On the other hand, if this were happening in a business context, I would call it "critical", since the appearance of a document is very important in that context. I have tried fixing this, but not recently. As I recall, OOo was claiming that the margins were larger than the page length when, of course, two margins totalling 1.5" cannot possibly be larger than a page length of 11". This may, or may not, be helpful to you.
Please attach example.
Created attachment 81097 [details] sample file showing the problem when printed This is a sample ODT file. I selected "binary file" in the hope that it would upload correctly. Please advise if it does not -- and advise what I should have selected. If you need anything else, please let me know. This problem began with 3.3 and is still present. It may need a Panasonic KX-P1624 to manifest itself. It will almost certainly need a dot-matrix printer with similar properties (including the physical positioning of the paper) to become apparent. Note that I am using continuous, tractor-fed paper, not separate sheets. Note that the first page prints correctly. it is the second and third pages that do not.
Thank you! The attachment prints OK to PDF. Unfortunately, I personally don't have access to dot matrix printer. I can suggest using OOo 3.2 just for printing, till a more expert person can analyse the problem.
Thanks for checking. Yes, these documents (one produced per month) do convert to PDF. I suspect that the second and third pages would print properly on my Epson Stylus, and any other printer using separate sheets, although I have never bothered to try. By converting it to PDF you have confirmed that the file arrived in useable form. And that is appreciated.
I finally managed to do some additional tests, which may through some light on the problem. When I modify the format for the first page to be 9.5" deep and reduce the bottom margin to 0, the second (and subsequent) pages have a top margin of 0.5" and a bottom margin of 1". Note that this is an improvement on the original case, where the top margin on the second and subsequent pages was 1.5" and the bottom margin was 0". Modifying the first page again to show a depth of 9.75" and a bottom margin of 0.25" once again produced, on the second and subsequent pages, a top margin of 1.5" and a bottom margin of 0". So, apparently, for the Panasonic KX-P1624 at least, the rule is: if the user /dares/ to put a non-zero bottom margin on the first page, all subsequent pages will add their top and bottom margins together and put them at the top. Otherwise, the top margin is limited to 0.5", any remainder being added to the bottom margin. I also played around a bit with the right margin, originally 2". Changing it to 0.5" on the first page caused some text, shown in OOo itself as on the line, to not print; changing the right margin to 1.5" (determined by using a ruler to measure where the text stopped abruptly with a right margin of 0.5") allowed all the text to print on the first page exactly as shown in OOo itself. A right margin of 0.5" worked correctly on the second and subsequent pages. Additional testing did not change these results, so the rule for the Panasonic KX-P1624, at least, appears to be: the first page right margin must be at least 1.5". Why this is happening is unclear, although I suppose it is possible that the program is reacting to the type of printer -- that is, that it checks to see if it is dealing with a dot-matrix (line-oriented) printer or a page-oriented printer and behaves differently in each case, in which case any dot matrix printer should show the same effects. It is, I suppose, possible that some pre-Apache programmer had it in for Panasonic and that this is specific either to Panasonic line-oriented printers in general or to the KP-X series or even the KP-X1624 in particular, but I have my doubts about that. Although I would think that, by now, dot matrix printers are scarcer than hen's teeth, and so the problem not very urgent, I could be wrong: I was pleasantly surprised to find, when I upgraded (if that is the word) to Windows 10 that it came with the appropriate Panasonic printer without having to download the additional drivers. Presumably, the drivers it comes with are the ones most likely to still be needed, and a lot of them appeared to be for dot-matrix printers, so dot-matrix printers may still be out there and in use by a lot of people.
Sorry, I cannot test your issue. But I don't understand, why the first page is shorter than the other pages? What are the minimal page/printer margins? Simply press "page down" if the cursor is in a margin input box. As I understand you use endless paper and I think the text should begin at the same position at all pages, right? What happens, if all pages have a hight of 11" and top margin 0" and bottom margin 1.5"?
The printer imposes a 0.75" (approximately) start-point for the first page, so the 11" would end about 0.75" into the second page and so on (with the tractor and continuous forms, the remaining pages would start printing at the very top if the first page were were set up to 9.50" and no top or bottom margins). (This forced 0.75" top margin on the first page is why I set the bottom margin on the first page and the top and bottom margins on the subsequent pages to 0.75".) This greatly restricts the number of programs I can use to print multiple pages: most allow only one format for all pages, and produce the 0.75" offset. OpenOffice avoids the problem by allowing different formats for the first page and the subsequent pages -- and did this correctly up through 3.2. This problem began with 3.3, which (IIRC) was done before Apache acquired OpenOffice. As I said, the behavior is /as if/ my printer (or the class to which it belongs) was being singled out for special treatment. This means that the problem might be reproduceable on any dot matrix printer, or any dot matrix printer that has an unprintable area at the top, or it may be restricted to Panasonic printers, or just to the KX-P1624. Has anyone looked at the code to see what it is actually doing? It very likely is distinguishing between line-oriented and page-oriented devices, but is it checking the line-oriented devices further? Are there any comments about changes done for 3.3 that shed any light on the topic? And, no, I have not used endless paper. I have used a monthly report I prepare for my brother to test various formats, and I only began that last fall. Although this is irritating, it is something I can live with. I posted my update simply because, having done the work, I felt I should share it, since the results do tend to shed further light on what is happening.