DYMO LabelWriter 450 Turbo Hatch Label print fails with margin error

[Blake GH]

EG 3.0.2
Hatch 0.1.3

This is specific to this model of printer and perhaps all Dymo's. Once you have Hatch handling printing, browse to /eg/staff/admin/workstation/printer/config
click Label
Choose the Dymo label printer, no need to change any of the preferences
Click "Test Print"
The error in the browser console (attached)

[Blake GH (bmagic)]

For spider and text searching:

Hatch command failed with status=400 and message=Illegal argument in print request: java.lang.IllegalArgumentException: Bad margins : {"settings":{"allPages":true,"pageRanges":[],"printer":"DYMO LabelWriter 450 Turbo","context":"label","autoMargins":true}

[Terran McCanna (tmccanna)]

Blake, is it only the Test Print that is failing, or is it failing from the spine label printing interface as well?

[Blake GH (bmagic)]

The print fails with a margin error message in the browser console when printing from the spine label interface. It doesn't seem to matter if you specify margins in the settings or not. It fails the test print and real prints but only to the Dymo. Any other printer will print just fine.

[Lynn Floyd (lfloyd)]

I'm seeing this with the Dymo Labelwriter 450 Duo also.

hatch.js:117 Hatch command failed with status=400 and message=Illegal argument in print request: java.lang.IllegalArgumentException: Bad margins : {"settings":{"allPages":true,"pageRanges":[],"leftMargin":"0","topMargin":"0","pageOrientation":"LANDSCAPE","rightMargin":"0","paper":"99016 Video Top","bottomMargin":"0","printer":"DYMO LabelWriter 450 DUO

We use the Duo's and Turbo's for all of our printing.

[Bill Erickson (berick)]

Hatch jar with stack trace logging on bad print arguments.

[Blake GH (bmagic)]

Bill,

I finally got around to getting this pushed properly.

http://git.evergreen-ils.org/?p=working/Hatch.git;a=shortlog;h=refs/heads/user/blake/lp1741299-hatch-dymo

[Christopher Burton (cburton)]

Can confirm this as we have Dymo 450s here and have the same issue that I just ran across today.
Is there any workaround for this?

[Blake GH (bmagic)]

Alright yall. I've finally got this in a good place:

http://git.evergreen-ils.org/?p=working/Hatch.git;a=shortlog;h=refs/heads/user/blake/LP1741299_DYMO_LabelWriter_450_Turbo_Hatch_Label_print_fails_with_margin_error

From the commit message:

This code will fork the HTML rendering away from webEngine when
a matching printer is selected. Dymo is the only case so far.
The rendering will instead be performed by JEditorPane/HTMLEditorKit.

JEditorPane has a much more rudimentary interpretation of CSS which
in-turn means that the templates will need some tweaking. For
example any CSS defined between <style> tags cannot be defined by
good old "class" dot DOM selectors. AKA .spine is not understood.
Instead, the template needs to use in-line styles on the DOM element
or a DOM selector by tag name. AKA "table tr td pre".

It might be a good idea to put out some release notes to that effect but I'm not sure where. Evergreen Repo?

[Blake GH (bmagic)]

Here is an example template where CSS does work:

<style>
table tr td pre {
font-weight: bold;
font-size: 19pt;
width: 150px;
}
</style>

<table class="labels" style="page-break-after: always;" ng-repeat="copy in copies" ><tr valign="top"><td>

<!-- Spine Label contents -->
<pre class="spine" style="text-align:left;font-size:12pt;border:none;margin-left:20px" ng-show="true">
{{get_cn_for(copy)}}
</pre>

</td><td>

<!-- Pocket Label contents -->
<pre class="pocket" style="border:none;left-margin:20px;font-size:10pt;" ng-show="true">
{{copy.barcode}}
{{copy['call_number.label']}}
{{get_bib_for(copy).author }}
{{get_bib_for(copy).title | wrap:28:'once':' '}}
</pre>

</td></tr></table>

[Blake GH (bmagic)]

Decided to bake this feature into the Evergreen code so that libraries can decide when the Hatch code should use it.

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/blake/LP1741299_DYMO_LabelWriter_450_Turbo_Hatch_Label_print_fails_with_margin_error

Hatch code changed as well. same link as above

[Bill Erickson (berick)]

It was really bothering me this was not working and shaking my confidence in the general approach, so I did some source code diving. I traced the problem to some faulty assumptions in the Java code (all printers have 3/4" on every side to spare!). In short, regardless of the margins you wished to apply, the underlying code would always create a default set in case it needed them, but the default margins were too big for the Dymos.

It's related to this bug:

https://bugs.openjdk.java.net/browse/JDK-8088918

Note the off-hand comment:

"One other thing that is not happening here but could happen is that the DEFAULT margins of 0.75" might be too much for a really tiny paper. I don't know that I've seen a paper < 1.5" in either dimension .. even a register receipt roll is bigger than that but we can also add some code to protect against that. "

The issue is fixed in Java 1.9+. I confirmed on Windows using version 1.11 (AKA "version 11") using the GPL-licensed zip bundles. https://jdk.java.net/11/ -- More documentation and probably some email discussion to follow on how best to update our Java version to resolve this.

Given the number of code changes required to get the Dymos working in 1.8, my preference would be not to merge the provided patches, but instead work toward updating Java (which presumably we'll have to do eventually anyway).

[Blake GH (bmagic)]

See bug 1817932

[Bill Erickson (berick)]

The margin error is resolved with changes made to bug #1817932. Marking this as duplicate.