1914238 - Unable to print TSP100 USB receipt printer with proper paper size

Status: NEW

(Core :: Printing: Setup, defect)

Description

[Josh Stompro]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:129.0) Gecko/20100101 Firefox/129.0

Steps to reproduce:

Try to print receipt on Star TSP100 and TSP100GT USB (XUbuntu 23.10)

Actual results:

Printer prints just a tiny slip with nothing on it when proper paper size (72mm x 2000mm) selected. When selecting 72x200 instead, it will print a bit of text on the far right side if the receipt.

Receipt printers like the TSP100 are setup to cut the paper at the end of the document, so they should cut right after the last line of output.

When a "normal" paper size like Letter is selected, it prints as expected, though as expected everything is scaled small when doing this. Setting print_scaling to 2 for 200% almost lets the output work this way. But it is still slightly too small. print_scaling = "2.5" would work, but isn't allowed by the scaling validation rules, "2" is the max.

Expected results:

Receipt should print normally. Same receipt works fine in Chromium 127.0.6533.119, works fine in mousepad editor. Also doesn't work in OpenKiosk which is based on firefox 115.12.0.

This was tested with a new profile on a test machine. So the profile is setup with default settings and hasn't been used for anything else.

This is a clone of bug 1766297, which was closed when no feedback was provided.

I'm willing to ship someone a TSP100 if that would help troubleshoot. I can supply any other output that would help.

Comment 1

[Josh Stompro]

Attachment: About:Support info

Comment 2

[Josh Stompro]

Unanswered questions From Bug 1766297

Can you attach your about:support information to this bug report? Done

If you're using Ubuntu's snap, can you test a build from https://www.mozilla.org/en-US/firefox/new/? I'll give it a shot.

Does this reproduce on a clean profile? Yes, only testing with clean profiles, brand new install of firefox on a test machine.
If so, does this reproduce on a regular profile if you click the "Clear saved print settings" button? Yes, The settings that I set after clearing are.

1. More settings
2. Uncheck print headers and footers
3. Margins None
4. Paper Size: 72 x 2000 mm (borderless)
5. Print (Results in the less than 1inch piece of receipt paper being outputted)

Is there any chance you could use mozregression to figure out when it broke? Something like this on the terminal should do:

$ pip3 install --user mozregression
$ MOZ_DISABLE_CONTENT_SANDBOX=1 mozregression --good 91
That should come up with a commit that broke the issue for you.

I'll try that out.

Comment 3

[Josh Stompro]

Installed from apt repo as described at
https://support.mozilla.org/en-US/kb/install-firefox-linux#w_install-firefox-deb-package-for-debian-based-distributions

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:129.0) Gecko/20100101 Firefox/129.0

No change in the behavior.

Comment 4

[Josh Stompro]

Trying out the mozregression stuff the first version that it gave me showed the problem. Firefox 92. I'll try and go back further.

Comment 5

[Josh Stompro]

I haven't been able to find an older version that works, went back to 31.0a1

59 MOZ_DISABLE_CONTENT_SANDBOX=1 mozregression --good 91
60 MOZ_DISABLE_CONTENT_SANDBOX=1 mozregression --good 80
61 MOZ_DISABLE_CONTENT_SANDBOX=1 mozregression --good 70
62 MOZ_DISABLE_CONTENT_SANDBOX=1 mozregression --good 50
63 MOZ_DISABLE_CONTENT_SANDBOX=1 mozregression --good 40
64 MOZ_DISABLE_CONTENT_SANDBOX=1 mozregression --good 30

Any suggestions on how to find the version that was mentioned in the previous bug? I'll work back from 101 I guess.

Comment 6

[Josh Stompro]

Tried a few more with no luck finding one that works.
66 MOZ_DISABLE_CONTENT_SANDBOX=1 mozregression --good 95
67 MOZ_DISABLE_CONTENT_SANDBOX=1 mozregression --good 96
68 MOZ_DISABLE_CONTENT_SANDBOX=1 mozregression --good 97
69 MOZ_DISABLE_CONTENT_SANDBOX=1 mozregression --good 98
70 MOZ_DISABLE_CONTENT_SANDBOX=1 mozregression --good 99

Comment 7

[Daniel Holbert [:dholbert]]

Thanks for the bug report and for all the information!

(In reply to Josh Stompro from comment #5)

Any suggestions on how to find the version that was mentioned in the previous bug? I'll work back from 101 I guess.

For reference: for this sort of investigation where you're just testing one-off versions (rather than bisecting between known-good/bad versions), it's a bit more direct to use --launch rather than --good. But that might not be useful at this point, since it sounds like you've already managed to determine that this issue goes back ~forever. (That's unfortunate and doesn't quite jive with bug 1766297's mention of "used to work fine in FF until a few months ago", but it's possible that that person's configuration was different in some meaningful way that made it work properly in older versions.)

Comment 8

[Josh Stompro]

I sent the an email to the submitter of bug 1766297 just in case they could fill in more details about when it worked correctly.

I have various different models of Star TSP100 printers. And they all seem to have the same problem.

Star TSP143U
Star TSP143IIU
Star TSP100ECO

Firefox in windows does work fine with these printers also. One thing I've noticed with windows vs linux is that in windows there are paper sizes like "72mm x continuous" (no length specified since it is a roll of receipt paper). While linux/cups doesn't offer those types of sizes.

Comment 9

[Daniel Holbert [:dholbert]]

I got a used Star TSP143IIU and can confirm that I get mostly blank output from Firefox when I choose a 72mm-wide paper-size, though printing to "US Letter" paper size works fine for me (the content just gets scaled down to fit).

If I choose e.g. 72mm x 110mm wide paper size in our print dialog "more settings" section, then the receipt paper ends up mostly-blank and unnecessarily tall (roughly 200mm I think), and I can just barely see the leftmost characters from the page, running off the right side of the receipt -- i.e. it looks like this (forgive the ascii art):

 ________
|        |
|        |
|        |
|        |
|        |
|       N|
|        |
|        |
|        |
|       1|
|________|

...where the "N" is from "Nightly" (the default top-left page-header-text for pages that lack a <title>), and "1" is for "1 of 1" (bottom-left footer text).

If I had chosen to print with no page headers, then the page would indeed be fully-blank.

If I print with zero print-margin and zero css margin, I can see some of the page's leftmost content appearing on the right side of my printed receipt, too.

Comment 10

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:boris, could you have a look please?

For more information, please visit BugBot documentation.

Comment 11

[Daniel Holbert [:dholbert]]

I've been playing around with the printer-driver-cups-pdf printer today (as distinguished from the Firefox built-in Save-to-PDF print target) and I'm observing that if I add and try to print to an "unusual"/nonstandard paper-size and try to print to it from Firefox, then I end up with A4-sized "virtual paper" in the PDF, with a page of my custom size printed onto the center of that paper. Whereas in Chrome, it just works; I end up with virtual paper of the correct custom size that I configured.

I think that might be what's going on here -- **I think maybe the receipt printer's e.g. 72x110mm page-size is being rejected by whatever bit of code is also rejecting my custom paper sizes, and we end up generating an A4-sized artifact with the 72x110mm output centered on it, and that's what we send to the printer, and it prints the top-left corner as best as it can, or something like that, which results in the rendering in comment 9.

As an example: if I manually add the following 6x7in paper-size called MyTestSize to /etc/cups/ppd/PDF.ppd, with each line inserted into the appropriate section with the same info for other page-sizes...

*PageSize MyTestSize/My Test Size: "<</PageSize[432 504]/ImagingBBox null>>setpagedevice"
*PageRegion MyTestSize/My Test Size: "<</PageSize[432 504]/ImagingBBox null>>setpagedevice"
*ImageableArea MyTestSize/My Test Size:  "0 0 432 504"
*PaperDimension MyTestSize/My Test Size: "432 504"

...(per e.g. StackOverflow or just cargo-culting from the existing ppd content), and I run sudo service restart cups, and then try to print to that paper size, then a few things go wrong:
(a) it shows up in Firefox's print dialog as 6 x 7 " (Borderless), notably not using the actual paper name that I specified in the PPD file. (This is maybe a hint that it's being rejected or not fully picked up.)
(b) the print job results in a PDF that shows an A4-sized piece of paper (confirmed in the PDF info shown by PDF.js), with the 6x7 page-content centered on it.
(c) If I click out to the system print dialog and click the Page Setup tab, I see Paper Size is set to a weird name custom_6x7in_6x7in_borderless, which is odd. If I scroll up in the paper-size-list, I see that there's also a page size named "My Test Size" in the system print dialog's paper-size-list for this cups PDF printer (notably that name is not present in the Firefox built-in print dialog). It doesn't matter which of these two sizes that I choose for the paper size in the system-print-dialog print operation, though; I still get the output described in (b).

In Chrome, all three of these work out correctly -- the paper shows up in the print dialog using the expected "My Test Size" name (in Chrome's print dialog as well as in the system-print-dialog), and I end up with a PDF that shows a 6x7 sheet of virtual paper (which is the same size as the page that's drawn onto it).

[1] (I'm not entirely sure what qualifies as "nonstandard" for this assessment or who/where that's being judged)
[2] note that the values in the PPD file seem to be in points, i.e. 1/72 of an inch.

Comment 12

[Daniel Holbert [:dholbert]]

Attachment: Chrome's PDF output, from printing to my 6x7in "My Test Size" paper-size with CUPS-PDF printer

Comment 13

[Daniel Holbert [:dholbert]]

Attachment: Firefox's PDF output from printing to my 6x7in "My Test Size" paper-size with CUPS-PDF printer

Comment 14

[Daniel Holbert [:dholbert]]

(er, sorry to @Emilie who I inadvertently CC'd. I was trying to CC @AlaskanEmily and flubbed the bugzilla user autocomplete.)

Comment 15

[Daniel Holbert [:dholbert]]

Here's a pernosco trace of me printing example.org to my aforementioned PDF printer with 6x7 paper size (and ending up with 6x7 page on an A4-sized PDF).

I've poked around in pernosco and added some guideposts in the Notebook view, but I'm not yet sure where things go wrong.

It does look like our custom size name (custom_6x7in_6x7in_borderless) comes from CUPS, and GTK complains when given that custom size name, but it's still happy to store it as a size-name. And we do seem to set the correct actual dimensions (in nsPrintSettingsGTK::mPrintSettings) when we set it up, in the nsPrintSettingsGTK instantiations I've traced through.

Comment 16

[Daniel Holbert [:dholbert]]

Attachment: WIP: Bug 1914238 proof-of-concept: don't force ourselves to use a standard page-size in nsDeviceContextSpecG initialization.

Comment 17

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] from comment #15

we do seem to set the correct actual dimensions (in nsPrintSettingsGTK::mPrintSettings) when we set it up, in the nsPrintSettingsGTK instantiations I've traced through.

I found the spot where we fail to do that: nsDeviceContextSpecGTK::Init gets a "standard page size" for our gecko page-size. That's the thing that's nudging us from our custom dimensions to A4 in this case.

The "standard page size" function GetStandardGtkPaperSize has a comment above it noting that it's a horrible workaround for some print driver bugs, so it's probably a bit fiddly to adjust without causing other fallout. But locally at least, if I bypass the results of that GetStandardGtkPaperSize function, then this bug goes away, both with my virtual CUPS-PDF printer (with the 6x7 custom page size) and with my actual receipt printer that was producing bogus output like the ascii art in comment 9.

Comment 18

[Daniel Holbert [:dholbert]]

Aha, OK -- so GetStandardGtkPaperSize almost does the right thing here (which would be to return our unmodified custom page-size), but it gets confused by GTK which is why it causes trouble.

This is the problem spot:
https://searchfox.org/mozilla-central/rev/3966e5534ddf922b186af4777051d579fd052bad/widget/gtk/nsDeviceContextSpecG.cpp#210-215

GUniquePtr<GtkPaperSize> size(gtk_paper_size_new(geckoName));
// gtk_paper_size_is_equal compares just paper names. The name in Gecko
// might come from CUPS, which is an ipp size, and gets normalized by gtk.
// So check also for the same actual paper size.
if (gtk_paper_size_is_equal(size.get(), aGeckoPaperSize) ||
    PaperSizeAlmostEquals(aGeckoPaperSize, size.get())) {

geckoName here is custom_6x7in_6x7in_borderless. We pass that to gtk_paper_size_new(), which creates a dummy GtkPaperSize for us -- it doesn't recognize the passed-in name (info ends up NULL), so GTK initializes the returned GtkPaperSize with A4 sizes as a fallback:

      info = lookup_paper_info (name);
      if (info != NULL)
        size = gtk_paper_size_new_from_info (info);
      else
        {
          g_warning ("Unknown paper size %s", name);
          size = g_new0 (GtkPaperSize, 1);
          size->name = g_strdup (name);
          size->display_name = g_strdup (name);
          /* Default to A4 size */
          size->width = 210;
          size->height = 297;

https://github.com/GNOME/gtk/blob/ea8062e86afdee5161deebcfb01e09ca7878186b/gtk/print/gtkpapersize.c#L254-L265

Then, we reach the check gtk_paper_size_is_equal(size.get(), aGeckoPaperSize) in my nsDeviceContextSpecG quote above. That check passes, because (per our code-comment) it's just checking whether the names match; and they do. So we end up returning size as the "standard size" even though really it's just a dummy size that Gtk dutifully created for us with bogus sizing.

Comment 19

[Daniel Holbert [:dholbert]]

Incidentally, Gtk almost successfully parses the custom name even though it's nonstandard, but it gets tripped up by the "_borderless" suffix.

The Gtk function parse_media_size reaches this point while parsing our custom page name. parse_media_size receives the string 6x7in_borderless and parses away 6x7 and then reaches this part:

  if (strcmp (p, "in") == 0)
    {
      short_dim = short_dim * MM_PER_INCH;
      long_dim = long_dim * MM_PER_INCH;
    }
  else if (strcmp (p, "mm") != 0)
    return FALSE;

https://github.com/GNOME/gtk/blob/ea8062e86afdee5161deebcfb01e09ca7878186b/gtk/print/gtkpapersize.c#L127-L133

At this point, "p" is the string "in_borderless" which is not an exact match for "in" nor for "mm", so we return FALSE.

If we lacked that "_borderless" suffix (or if Gtk could handle it when parsing), we would successfully parse a valid GtkPaperSize and we'd end up with useful dimensions instead of the A4 fallback ones, I think.

Comment 20

[Daniel Holbert [:dholbert]]

So I haven't tested, but I suspect part of the fix here would be to adjust parse_media_size in gtkpapersize.c to ignore _borderless as a suffix when comparing the units -- e.g. something like this, if I haven't flubbed the logic:

  if (strcmp (p, "in") == 0 ||
      strcmp (p, "in_borderless") == 0))
    {
      short_dim = short_dim * MM_PER_INCH;
      long_dim = long_dim * MM_PER_INCH;
    }
  else if (strcmp (p, "mm") != 0 &&
           strcmp (p, "mm_borderless") != 0)
    return FALSE;

I think that would fix things for the cases here. But we probably also want to try to handle the case where we trip the Unknown paper size A4-fallback situation in comment 18 -- maybe even just by directly checking for A4 sizes in the returned object and then applying extra scrutiny, if there's not a better way to detect the Unknown paper size Gtk-fallback situation.

Comment 21

[Josh Stompro]

It looks like this might be a GTK bug, so I started a bug report over at the gtk gitlab instance.
https://gitlab.gnome.org/GNOME/gtk/-/issues/7363

Comment 22

[Daniel Holbert [:dholbert]]

Yes it is; thank you!

(Despite being a GTK bug, it's still one that we'll need to work around for the forseeable future, and I need to carve out some time for it.)

Comment 23

[P&W]

Good day, we are also experiencing this bug on a Epson TM-T88V Thermal Receipt printer, so this issue seems to be affecting more than just one brand of printer.

Is there any timeframe for when this bug might be fixed?

Is there any temporary workaround for Firefox while the bug is being fixed?

Printing inside other programs like Inkscape or other browsers like Chromium works perfectly.

Kind Regards

Comment 24

[Daniel Holbert [:dholbert]]

(In reply to P&W from comment #23)

Good day, we are also experiencing this bug on a Epson TM-T88V Thermal Receipt printer, so this issue seems to be affecting more than just one brand of printer.

Thanks for letting us know -- yeah, this is known to affect any printer that has "borderless" sizes, if you choose one of those page sizes.

Is there any timeframe for when this bug might be fixed?

Not currently; it's on my radar but I'm not working on it immediately (in part because the bug here is in GTK code, external to Firefox; though we may be able to hack around it somehow). In any case, thanks for the nudge; knowing that more users are affected is helpful with prioritizing correctly.

Is there any temporary workaround for Firefox while the bug is being fixed?

As I recall, you might get better results if you choose some non-"borderless" size, as the paper-size in the print dialog, probably? Printers may or may not offer you that flexibility, though.

Printing inside other programs like Inkscape or other browsers like Chromium works perfectly.

That's likely because they use CUPS/GTK in a slightly different way than we do, and they're lucky enough not to trigger the GTK bug.