Printing bug since FF 56 - first page is fine but data on page 2 is missing!?
Dear community,
we print invoices out of html. In html the invoices are fine. As soon as we hand over the data to the printer (printer preview) only the first page is fine.
On the second page the address data and whole top adress block is missing!? Since 10 years we use this data format and never had issues.
We use commands like <TABLE cellSpacing=0 cellPadding=0 width="100%"> <TBODY> <TR> <TD noWrap width="40%">
etc.
On chrome everything works fine. Other customers who use the invoice software report the same issue with FF 56.
We need to use chrome now...
Thanks Heiko
Moambuepyre
Opaite Mbohovái (20)
Hello Sotel, sorry to ear about that. Can you start you Firefox in safe mode and tell us if problem persists ?
Same issue. :(
As soon as i hit the print button and see the preview window the second page has missing data. (no address data of the customer etc.)
The complete top block is missing.
Thanks for the feedback. Do you have the possibility to share with us an URL? I'd like to reproduce the bug and try to identify which part of the template may cause the issue.
We use afterbuy.de - a seller software.
I just printed delivery notes out of the same system. They work. But have a differenct code format then the invoice which cause this issue.
It seems like FF 56 has an issue with a format / FONT command. But its crazy that the FIRST invoice / page works fine and on the second page the address data field / top block is empty.
The top of the code starts with:
TABLE width=650 TBODY TR TD colSpan=2 TABLE cellSpacing=0 cellPadding=0 width="100%" TBODY TR TD noWrap width="40%"
and we close it with:
/div /P /STRONG /FONT /TD /TR /TBODY /TABLE
Everything in between are many td and div commands for the format.
Moambuepyre
Yes, I agree, the <font> feature do not have to be exploited, it obsolete, table too (except to construct a real table) You can find more information here:
</font>
Moambuepyre
But why does it work for the first page / invoice and not for the other ones?
I would need an entire HTML document to check his validity and find a complete help. Can you provide an entire HTML page? You can find my email address if you want to send it to me in private.
You can possibly check the page source in Firefox to see if the are tags in red to indicate errors. You can hover such a red tag to see a descriptive tooltip.
If you chose widescreen the data appears!? It seems as Firefox kills the data if the table is too large for the A4 page!?
@morele - just send an exmaple
thanks Sotel for your email. As web developer, I'm quite sure the issue is due to a wrong HTML structure. It took me less than 2 minutes to identify some problems, and the W3C validator can returns you the same if you need.
A word about Html. It's a kind of structural language which gives many pieces of information about page rendering. If the HTML structure is not well defined, browsers try to do the best to present something but the presentation (on the screen or printed) may be crappy and it's exactly what happens here.
I would recommend you to take time to improve your HTML structure to guarantee browser support, there is nothing we can do for you in this precise case :(
Hope this help!
Did you use some Microsoft Office editor to create the page?
If that is the case then best is to look for a more 'sturdy' HTML editor.
No - we created it by ourselves. So the code is not the best and not the worst ;)
But we have many tables and div commands. I guess we didnt close on table correct and this ruines the second page layout then.
The last 10 years FF accepted it - FF56 isnt that gentle :(
Thanks for the WC3 hint. In the end we did break down the code until it has been WC3 valid....and it still didnt work.
Its this simple code:
TABLE width=650> TBODY> TR> TD colspan="2">
TABLE width="80%"> TBODY> TR> td>
TEST - this works!
-KFirma->BR>-KVorname-> -KNachname->BR>-KStrasse-> BR>-KAnschrift2->
FONT face=Arial size=3>B>-KLand->--KPLZ-> -KOrt->/P> --KLandPost->- /FONT> <P>Phone: -KTelefon->/P>/B> /TD> /TR>/TBODY>/TABLE> br><p> /TD>/TR>/TBODY>/TABLE> After we deleted the table inside the table it works now. (TABLE width="80%") But a WC3 valid code should be printable!?
Sotel a écrit
But a WC3 valid code should be printable!?
yes, I should let's see when you will have a valid HTML :-)
As a footnote, there is a known issue in Firefox 55-56 with tables that have the border-collapse: collapse style: after the first page, the borders between cells are missing. However, it sounds as though you have a different issue.
Can you can save a static HTML version of the page with substitute (fake) data and post it somewhere? One site for posting HTML is Pastebin, but if you do it anonymously (without an account), you can't delete it later.
Here it is: https://pastebin.com/aTAQC6Ap
W3C CSS valid W3C Markup - This document was successfully checked as HTML 4.01 Transitional!
Are you able to edit the template for this page in any manner? If you can add CSS, please try this:
<style type="text/css"> table table { margin-top: 0.1px; } </style>
That causes the embedded tables to have a 0.1px margin at the top, which prevents the top border of the table from merging with the top border of the cell. I don't know exactly why that helps, but it helps.
There may be other hack-arounds, but hopefully this one is quick to implement if you can modify the template that generates the page.
This is slightly more targeted:
<style type="text/css"> td > table:first-child { margin-top: 0.1px; } </style>
We can only edit the code below the the "table=650". The CSS comes from the software company.
But i removed the second table inside the "big" 650px table now and it works!?
If you do not need tables inside of tables, then you're okay.
If you do need tables inside of tables, there needs to be a separation between the embedded table and the cell it is embedded in:
<td> <table> PROBLEM
<td>Some Text <table> OKAY
<td> <table style="margin-top:0.1px"> OKAY