Unable to format HTML style word-wrap: break-word property for very long unbroken word in printHTML

[GoogleCodeExporter]

Hello,

I'm running jzebra version 1.8.7 and currently making some test for retail 
receipt printing on an Epson TM-T90 printer with 3 inch wide receipt paper 
roll. I have discovered that the qz.printHTML() method doesn't quite recognize 
the style property: "word-wrap: break-word;" on the <td> tag within <table> 
when the <td> content has a very lengthy unbroken word.

How to reproduce the test:
I have attached a zip file containing wordwrapdefect.html, when this file is 
run on a web browser, it will have 2 buttons namely:
1) Print Now -> which prints the html contents for correct printout formatting
2) Print Now (Defect) -> which didn't wrap the lengthy word and as a result the 
printout wasn't quite as expected.

Extract the wordwrapdefect.html file and place it in the qz-print folder (the 
folder which is bundled in qz-print-free_1.8.7_src.7z), deploy it on a web 
server and run http://localhost/wordwrapdefect.html. Just click on the Print 
Now (Defect) button with the printer up and running and you should be able to 
see what I mean.

I'm running the jzebra applet on:
:- JRE Verion 8 Update 20
:- Windows 8.1 x86-64

Would truly appreciate any help on this. Thanks for the effort.

Original issue reported on code.google.com by wargu...@gmail.com on 4 Oct 2014 at 6:56

Attachments:

• wordwrapdefect.zip

[GoogleCodeExporter]

Correct.  This won't be fixed as Java's built-in HTML renderer is very poor and 
does not warrant the multiple pages feature.

The HTML5 printing renders much better, but still suffers the same single page 
size limitation.  We currently don't have a solution for this multiple-page 
problem, sorry for the inconvenience.

We have some premium clients using an experimental build of qz-print that has 
PDF-BOX embedded which is capable of properly rendering multiple pages, however 
due to poor embedded-font support, it is not ready for our stable version of 
the software.

Original comment by tres.fin...@gmail.com on 6 Oct 2014 at 1:39

[GoogleCodeExporter]

For now I am going to recommend you use ESC/P syntax with raw printing as that 
is the industry standard for thermal point of sale printing.  I understand that 
is an inconvenience when compared to the ease of HTML receipts, but the 
technologies you are combining simply aren't ready for eachother yet.

Original comment by tres.fin...@gmail.com on 6 Oct 2014 at 1:41

[GoogleCodeExporter]

Original comment by tres.fin...@gmail.com on 6 Oct 2014 at 1:41

• Changed state: WontFix

[GoogleCodeExporter]

Thank you very much for the reply and thanks for the time for such valid 
explanation. I'll see what work around I can find for this issue then.

Original comment by wargu...@gmail.com on 6 Oct 2014 at 3:36