Page 2 of 2

Re: NWP on Label Stock

Posted: Thu May 12, 2016 12:34 pm
by Gabriel
Ok, I'll see what I can do.

In the meantime, here's more information about the problem:

https://www.google.com/search?q=4.88+x+ ... BSgA&dpr=1

You'll notice there are lots of google posts about this specific printer defaulting to 4.88 x 11 in just certain programs but not most programs.

So its a combination of an issue with this hokey printer combined with an issue with BR that makes it so that clicking "Select Printer" then "Ok" without changing anything works.

Note that I did not include the model number in the search above .. just search for "zebra 4.88 x 11" and you see a bunch of results all for this specific model of printer (the 2844-z)..

Gabriel

Re: NWP on Label Stock

Posted: Thu May 12, 2016 1:35 pm
by bluesfannoz
Can you see what happens if you send the following PCL at the start of your code sent to the printer

Code: Select all

CHR$(27)&"&l2A"
That is suppose to make it use the default size the driver has set

Re: NWP on Label Stock

Posted: Fri Sep 03, 2021 10:03 am
by mikemiller
I know this is an old thread but I just came across it and thought it sounded familiar.

After a little digging I realized it was from a bug I discovered a few months ago.
The cause was an improperly cased escape sequence in an NWP substitute statement.
The bug in question was this:

Code: Select all

PRINTER NWP [LABELCODE], "\E(s66v"
Note how the "v" is lowercased when the correct statement would be:

Code: Select all

PRINTER NWP [LABELCODE], "\E(s66V"
The bug has the interesting side effect of "eating" the next character or escape sequence it meets.
So an innocent print command like this simply eats the first "C"

Code: Select all

PRINT #255: "[POS(+0,+.5)][LABELCODE]CCODE "
However, a more interesting case is when you follow it up with positioning:

Code: Select all

PRINT #255: "[POS(+0,+0)][LANDSCAPE][FONT ARIAL][BOLD][LABELCODE][POS(+0,+.5)]"
It will then eat your positioning and make it appear like your printer isn't responding to it.

So if anyone encounters something like this in the future, you may want to check the casing in your escape sequences.