HTML receipt cuts-off intermittently

[mlscherer]

Sorry for the generic title, but I couldn't think of a clear way to report this issue.

We have reports of a problem that happened on 3 or 4 printers that we are trying to use with qztray. We've configured well over 50 printers and the vast majority work perfectly, so it doesn't seem to be implementation related...

Basically, we only use HTML prints, and in these specific cases, it seems that the print stops in the middle of the job, and in the vast majority of reported cases (perhaps even 100%), the print stops on an element that we print with a black background (I attached some examples to get an idea). RAW prints work normally on these printers.

Looking deeper, I have the impression that it jumps from one black element to the other, printing the beginning of one, the "#647 (Retirada)" one and the end of another, skipping all the rest of the middle content (I highlighted the text "Entregar às 17:23" in the image showing it...). Suspecting this, we tried to remove this all black element, but the problem keeps happening...

Another thing I noticed, the first print with the bug has the line "REIMPRESSO" at the beginning, while the second print does not. On the second print, the black pad printed a little bigger... Perhaps this indicates some size limitation or something like that?

Thought it might be a printer hardware limitation, but at least 2 of the reported printers we also have working using the same driver version installed in the same client.

A customer reported this problem and before we could analyze it, he came back minutes later saying that the printer was connected to a power surge and when connecting directly to the power, it worked correctly (doesn't seem to make sense, but...). No other customers who reported the problem use surge protectors or nobreaks.

Any idea of tests we can do in these cases? Have you ever been through something similar?

Thanks.

[tresf]

Are you using HTML for printing? If so, this could be a timing issue related -- in part -- to #547. Fixing HTML race conditions have been a major effort on our part (as well as working directly with the upstream HTML engine authors -- JavaFX).

• What OS? (Windows, Linux or Apple?)
• What Architecture (x86_64 or ARM64/Apple Silicon?)
• What exact driver and/or hardware?
• Can you provide this bug report with a sample "print" log entry for reproducing?

Your answers to the above questions will help us escalate this issue.

[tresf]

... in the event that this is a hardware anomaly, there's a good chance moving the power plug and resetting the power could have corrected the issue, but if that's the case, the printer's firmware version may come into question, since a corruption in the printer's memory could also explain the issue.

[tresf]

Closing due to lack of response. Please feel free to request a reopen if the above questions can be answered.

[tresf]

The logs were examined.

• OS: Windows
• Architecture: x86_64
• Printer: Bematech MP-2800 TH
  
• Type: HTML

The HTML was tested 200 times in a row and each time QZ Tray did not cut off the content. We are attempting to gather more information about the steps related to reproducing this.

[mlscherer]

Hello! I found another customer going through this situation... With this customer I was able to do more tests and with that I identified some interesting points:

1 - The client has 2 identical printers (Print ID Touch), both connected via a network cable. One works perfectly all the time. The other one is having this same error...

2 - When changing the print configuration from 80mm to 58mm in our app, printing works correctly, but obviously using only the space of 58mm on the paper (in this configuration we change the parameter "size: width".... This may be interesting, cause we're sending the exactly same file, the only difference is this parameter.

3 - I tested changing the paper size setting in printing preferences, here:

I changed from "Normal 72mm Small" to Normal 72mm Large" and it printed correctly, but only the first print after changing the configuration. After printing correctly 1x, I tried to send other jobs and the same error happened. I did this three times, changing this setting and then go back to the default. The three times, it printed correctly 1 copy and printed with error all the others afterwards...

I hope this may help someone to figure this out... Thanks

[tresf]

Can you find "Normal 27mm Large" and find out the dimensions?

1. Start, Run (or Windows + R)

2. control printers

3. Click on printer

4. At the top of the window, click "Print server properties"

   

5. On the "Forms" tab, look for a form called "Normal 27mm Large"

6. Look for the Paper Size of this form

Then see if sending these dimensions to QZ Tray allow it to be selected each time.

Also, when you changed this setting, did you use:

• Printer Properties, Advanced, Printing Defaults? -- OR --
• Printer Properties, General, Preferences?

I've seen bugs with print drivers that respect one but not the other.

[mlscherer]

Hello Tres.

As this is a rare problem, I couldn't do more tests and I didn't have more information to add here before... Yesterday I managed to go personally to the customer who was experiencing this problem and managed to sort of solve it.

Arriving at the customer, I tried to change the printers, putting one of mine in place of his and the same problem continued to happen (on my printer, which never happened before). After a little bit more testing, I found out that the problem was being caused by the printer's power supply...

I changed the power supply for mine and it solved it... After that, just to be safe, I tested several combinations of printers, computers and USB cables, but the problem only happened with that specific power supply he had....

We have another customer going through this situation. I already warned him about the power supply and I'm waiting for him to test with another one to confirm if it really was the same problem... As soon as I get a response, I'll let you know here...

A detail that is strange... RAW prints work perfectly fine with that power suply... The problem only happens when trying to print HTML. Due to these details, it is still strange for me to imagine that it really is about the powe suply, dont you think? Theoretically it would also cause problems when printing RAW, wouldn't it?

I'm leaving these details here, so maybe brings you some insight that might help identify if there is any possible improvement in the app...

In any case, as soon as we get a response from the other customer, to ensure that it really is the same situation, we will consider this problem solved and we will leave an internal note that if it happens again, the customer must change the power supply...

Thanks!

[tresf]

I guess I can see the motor and heater failing in predictable ways when under-voltage occurs, but I agree, it's peculiar that it's not happening with raw.

The way that HTML/PNG/PDF works on these ESC/POS receipt printers is the printer driver must force the printer into a mode where it can print much finer and without line spacing, which is more taxing on the hardware. This can be observed by printing raw and HTML content side-by-side, the HTML will take considerably longer to print.

That said, I'm curious if the power supply actually fixes it for the next customer. Just to be clear, swapping back the problematic power supply caused the problem to resurface, right? And it was 100% reproducible?

[mlscherer]

Hi Tres, yes, swapping back the problematic power supply caused the problem to resurface, and I was able to reproduce several times, both using the customer's printer and using my own printer with his power supply.

As soon as I receive confirmation from the other customer that the problem has been resolved by changing his power supply, I will let you know

Em sex., 21 de jul. de 2023 às 22:46, Tres Finocchiaro < @.***> escreveu:

I guess I can see the motor and heater failing in predictable ways when under-voltage occurs, but I agree, it's peculiar that it's not happening with raw.

The way that HTML/PNG/PDF works on these ESC/POS receipt printers is the printer driver must force the printer into a mode where it can print much finer and without line spacing, which is more taxing on the hardware. This can be observed by printing raw and HTML content side-by-side, the HTML will take considerably longer to print.

That said, I'm curious if the power supply actually fixes it for the next customer. Just to be clear, swapping back the problematic power supply caused the problem to resurface, right? And it was 100% reproducible?

— Reply to this email directly, view it on GitHub https://github.com/qzind/tray/issues/1107#issuecomment-1646374462, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJ7447O5O44LOQB5MKZLIGLXRMWIJANCNFSM6AAAAAAWFWXP64 . You are receiving this because you authored the thread.Message ID: @.***>

[tresf]

@mlscherer thank you for tracking this down. I think you've stumbled upon a solution which no one in their wildest dreams would have imagined, and for that, you probably will save many people grief experiencing the same issue.