DYMO LabelWriter 450 Turbo Hatch Label print fails with margin error

Bug #1741299 reported by Blake GH on 2018-01-04
This bug report is a duplicate of:  Bug #1817932: Update Hatch Java / Javafx versions. Edit Remove
This bug affects 4 people
Affects Status Importance Assigned to Milestone

Bug Description

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) wrote :

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) wrote :

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) wrote :

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.

Blake GH (bmagic) on 2018-01-11
tags: added: webstaffclient
Lynn Floyd (lfloyd) wrote :

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.

Lynn Floyd (lfloyd) on 2018-03-05
Changed in evergreen:
status: New → Confirmed
Bill Erickson (berick) wrote :

Hatch jar with stack trace logging on bad print arguments.

Blake GH (bmagic) wrote :
Galen Charlton (gmc) on 2018-07-25
tags: added: hatch printing
Blake GH (bmagic) on 2018-10-15
Changed in evergreen:
assignee: nobody → Blake GH (bmagic)
Christopher Burton (cburton) wrote :

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) wrote :

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


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) wrote :

Here is an example template where CSS does work:

table tr td pre {
font-weight: bold;
font-size: 19pt;
width: 150px;

<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">


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


Blake GH (bmagic) wrote :

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


Hatch code changed as well. same link as above

Blake GH (bmagic) on 2019-01-31
tags: added: pullrequest
Changed in evergreen:
assignee: Blake GH (bmagic) → nobody
Bill Erickson (berick) wrote :

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:


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) wrote :
Bill Erickson (berick) wrote :

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

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers