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
NWP on Label Stock
Moderators: Susan Smith, admin, Gabriel
-
- Posts: 291
- Joined: Fri Jun 19, 2009 9:01 am
- Location: Lawrence, Kansas
- Contact:
Re: NWP on Label Stock
Can you see what happens if you send the following PCL at the start of your code sent to the printer
That is suppose to make it use the default size the driver has set
Code: Select all
CHR$(27)&"&l2A"
Steve Koger
Computer Specialist
SEKESC-MACS Division
Computer Specialist
SEKESC-MACS Division
-
- Posts: 13
- Joined: Wed Mar 17, 2021 6:01 am
Re: NWP on Label Stock
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:
Note how the "v" is lowercased when the correct statement would be:
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"
However, a more interesting case is when you follow it up with positioning:
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.
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"
Code: Select all
PRINTER NWP [LABELCODE], "\E(s66V"
So an innocent print command like this simply eats the first "C"
Code: Select all
PRINT #255: "[POS(+0,+.5)][LABELCODE]CCODE "
Code: Select all
PRINT #255: "[POS(+0,+0)][LANDSCAPE][FONT ARIAL][BOLD][LABELCODE][POS(+0,+.5)]"
So if anyone encounters something like this in the future, you may want to check the casing in your escape sequences.