Level 1

0 points

Help with custom page size support for non standard paper

Firstly, we appreciate any support you may be able to provide, we have already thrown considerable effort at this and it has been very time consuming and frustrating.

To support a number of business functions need to print to (non standard) continuous and mulitpart paper on a dot matrix printer. The (test) Mac is a 10.4.11 G4 laptop, the printer is an Oki Microline 520 (9 pin 80 column, IBM Proprinter, Microline or Epson FX personalities with a parallel interface) which has been networked via a HP JetDirext Ex Plus print server. That part appears to be operating correctly.

We have tried a number of drivers / printer personalities with varying levels of success:

ESP / EPSON 9-Pin Series CUPS v1.1 / Epson FX personality
ESP / OKIDATA 9-Pin Series CUPS v1.1 / Oki Microline personality
Ghostscript / epsonc / Epson Dot Matrix Foomatic PPD / Epson FX personality
Ghostscript / ibmpro / IBM ProPrinterII Foomatic PPD / IBM Proprinter personality
Ghostscript / okiibm / Oki Microline IBM compatible 9 pin Foomatic PPD / IBM Proprinter personality

There were no appropriate drivers in Gutenprint (5.2.3 version) The most successful is the okiibm / Oki Microline IBM compatible 9 pin settings, it can print A4 and honors the Printer Features Resolution settings in the print dialogue.

Q1: Should we see anything in the Printer Info / Installable Option, it is always blank ?

The issue is custom page sizes, we can manage / add Custom Pages Sizes via the Page Setup / Paper Size interface and they draw on the screen OK but they do not work at the printer (various issue at the printer such error messages, junk printing and wrong orientation):

Q2: Are we heading in the right direction or is there a better way to handle this ?

Q3: Would 10.5 solve all our problems, are the print drivers any better ?

Q4: Is this the correct way to specify custom page sizes, is this all we need to do ?

Q5: Is so how do we get the driver to respect the size, do we need another filter or something ?

Q6: Is it possible to add (by hand) custom page sizes to the ESP drivers or Foomatic PPD files so they they appear as a "standard" offering in the Page Setup / Paper Size interface ?

Sorry for the long / complicated post and thanks in advance for any advice / assistance.

1.67 GHz G4 laptop, Mac OS X (10.4.11)

Posted on Jun 3, 2009 11:11 PM

29 replies

BDAqua

Level 10

250,259 points

Jun 7, 2009 10:27 PM in response to Hetsr

Can you set it to 8 lines per inch?

Hetsr Author

Level 1

0 points

Jun 7, 2009 11:50 PM in response to BDAqua

I assume you mean the printer Rear Feed Line Spacing setting (that is how I am feeding the paper), is that correct ?

If so what effect do you think it may have, I would have thought that only applied to character based printing (response to a line feed character type stuff) and that this would be bit map/ graphics based printing.

Thanks Hetsr

BDAqua

Level 10

250,259 points

Jun 8, 2009 11:23 AM in response to Hetsr

I'm not sure, but it seems likely, or at least possible that the LF is converted to a graphic space of a certain size... I was thinking more of changing it in the Print dialog if possible, or the PPD.

Jun 8, 2009 11:38 AM in response to Hetsr

Thanks for posting the files. That was an excellent presentation. I was able to correlate what you did in Word, how you set up your paper sizes, etc with the CUPS error_log which was set in debug mode.

Mainly what I was looking for in the CUPS error_log was the consistency between the page sizes you set and whether the printing system was following them. For instance, your Job 113 showed the following in the error_log:

<pre style="overflow: auto;font-size:small; font-family: Monaco, 'Courier New', Courier, monospace; color: #222; background: #ddd; padding: .3em .8em .3em .8em; font-size: 9px;">D [07/Jun/2009:09:28:05 +0930] [Job 113] argv[5]="document-name=Preview\ of\ "Microsoft\ Word\ -\ Test_4_1_24.doc".pdf Resolution=120x72dpi AP_D_InputSlot= pserrorhandler-requested=standard nocollate media=Custom.288.00x89.28
. . .
D [07/Jun/2009:09:28:05 +0930] [Job 113] cgpdftoraster: size->width = 288, size->length = 89.28, size->top = 71.28, size->bottom = 18, size->left = 18, size->right = 270
D [07/Jun/2009:09:28:05 +0930] [Job 113] cgpdftoraster: PreferredRotation = 90
D [07/Jun/2009:09:28:05 +0930] [Job 113] cgpdftoraster - languageLevel = 3, mediaBox.size.width = 288, mediaBox.size.height = 89.28
</pre>

Your custom paper sizes and margins seemed to be honored. This is consistent with what the print preview showed.

At this point, my only thought is that the printer driver is not interpreting the page size print preview would indicate.

Do you get the same spacing results if you Save to PDF and then print the PDF?

Matt

Jun 8, 2009 11:41 AM in response to BDAqua

BDAqua wrote:
I'm hoping Matt stops back in! 🙂

I never left. 😉 I have been trying to keep up with this, but I am just in one of those periods where time is very scarce.

Matt

Hetsr Author

Level 1

0 points

Jun 8, 2009 5:03 PM in response to Matt Broughton

Matt

Thanks for the analysis, I trust we are getting closer to finding the root cause of the problem.

Regarding App > PDF > Printing, sorry the result appears to be the same. I created two PDF's one from File Maker Pro and the other from Word and both printed with form lengths = 50 mm. Consistent with the prinitng directly from Word (via print preview).

FYI: they were not included in the original report but the PDF files and CUPS log are in the zip file (printertestfiles2.zip)

http://www.keepandshare.com/doc/view.php?id=1225005&da=y (again a public file)

There appears to be a consistent (but non linear) translation from the Word etc / PDF / CUPS page size to the page size at the printer.
I will try changing the LPI to 8 LPI (BDAqua post: 8/06/2009 14:57) to see if it has any impact on how the printer responds and let you know the outcome.

Q: If it is in the driver, where to next ?

(ongoing thanks)

Jun 8, 2009 5:55 PM in response to Hetsr

Hetsr wrote:
Thanks for the analysis, I trust we are getting closer to finding the root cause of the problem.

Hopefully yes. That does not mean that we can find a solution. 😟

Regarding App > PDF > Printing, sorry the result appears to be the same. I created two PDF's one from File Maker Pro and the other from Word and both printed with form lengths = 50 mm. Consistent with the prinitng directly from Word (via print preview).

I would expect that, but it had to be verified. Sometimes printing from an application does produce different results than what Preview shows.

There appears to be a consistent (but non linear) translation from the Word etc / PDF / CUPS page size to the page size at the printer.
I will try changing the LPI to 8 LPI (BDAqua post: 8/06/2009 14:57) to see if it has any impact on how the printer responds and let you know the outcome.

I hope changing to 8 LPI fixes the problem or at least furthers the cause. It would be wonderful if we could find some sort of "page eject" or "form feed" constant.

Q: If it is in the driver, where to next ?

If it's in the driver, there really isn't anything we can do about it. I am not a programmer, so I only get glimpses of what is happening when I look at the source code. It depends on how many comments the developer leaves in the code. In this case, I did not see anything that provided any further insight into how a page is ejected.

One other thing you can test is to go back to the 'okiibm' driver from OpenPrinting. Make sure you have Foomatic-RIP and Ghostscript installed. Then try the customized PPD from my site http://webpages.charter.net/mbroughtn/beta/Oki-MicrolineIBM_compatible_9pin-okiibmCUSTOM.ppd.gz. Add a new printer using this PPD. I have added a paper size called "Label1". The paper size is specified as 4 inches x 1.5 inches with 0.25 inch margins left and right and 0.5 inch margins top and bottom. I also changed the CUPS filters that it will use (different than the PPD from OpenPrinting). Hopefully that driver will work better now.

Matt

BDAqua

Level 10

250,259 points

Jun 8, 2009 8:02 PM in response to Matt Broughton

I have all those codes somewhere...

chr$(12) was Home or Form Feed depending, will check at work tomorrow on my Ataris for the Lines per inch codes and such if that helps.

Hetsr Author

Level 1

0 points

Jun 9, 2009 8:01 AM in response to Matt Broughton

Matt, BDAqua, all,

The saga continues. I have completed some more testing and this time got a different result but I'm not sure if its a better result. The report should be available here:

http://www.keepandshare.com/doc/view.php?id=1225909&da=y

In short the 6 / 8 LPI printer setting appears to have little impact on form height, as does skip over perforation. The interesting things are:

1) We can consistently print on every second label
2) The custom page sizes are acting the same way as the CUSTOM label1

Q: Any idea why the CUSTOM ppd should introduce the every second label print ?
Q: It looks a bit like the custom page sizes are following the earlier label1 settings, do you know of any cacheing going on here ?

Hope we are coming to some sort of close / finish / crash

(ongoing thanks still, hetsr)

BDAqua

Level 10

250,259 points

Jun 9, 2009 12:08 PM in response to Hetsr

ESC "A"chr$(18)= 18/72nds linefeed.

ESC+"2"= 6 lpi

ESC+"0"= 8 lpi

ESC+"&k0S"= 10 pitch

ESC+"(s0P"= fixed pitch

Jun 9, 2009 5:28 PM in response to BDAqua

Thanks for posting those BDAqua. I don't find any of them in the ratertoepson.c filter code. Most current version of the filter code can be found in svn at http://svn.easysw.com/public/cups/trunk/filter/rastertoepson.c.

I suspect that it is more complicated than that. The rastertoepson filter is used for a number of Epson printers, both dot matrix and ink jet. I suspect that the current place on the page is calculated and the paper advanced an appropriate amount to eject. Then a new page is being loaded. Gets a bit complicated when one uses continuous forms.

Matt

Jun 9, 2009 5:58 PM in response to Hetsr

Hetsr wrote:
1) We can consistently print on every second label

That is progress of a sort.

2) The custom page sizes are acting the same way as the CUSTOM label1

That is expected assuming all parts of the printing system are working together properly. The extra paper entry in the CUSTOM PPD was just to ensure that Ghostscript would get the proper bounding box (page size).

Q: Any idea why the CUSTOM ppd should introduce the every second label print ?

That is probably the best we can do in the near term. My guess is that the okiibm driver may have a minimum paper height of 3 inches. With 1.5 inch labels, that would equate to every other label.

Hope we are coming to some sort of close / finish / crash

In the short term, I don't think I can assist in getting any better results than consistently printing every other label. Is that a work flow that might work - print every other label, use what you have printed and then reload the roll of labels so you can print on the ones that were missed?

In the longer term, I would hope I can get more insight by posing the problem on other (mainly developer) forums. In fact, you could also post your questions. I would post a question about the Epson 9-pin 1.3 driver to the general forum at http://www.cups.org/newsgroups.php?gcups.general+T. Good candidates for that forum would be your Jobs 110 and 111.

Questions about the okiibm driver that is printing every other label are probably best asked on the Ghostscript developers mailing list. See http://www.ghostscript.com/mailman/listinfo/gs-devel

Unfortunately, I won't have much, if any, time to follow through for the next couple of weeks and I don't guarantee that even with the respective developer's help that any better result will be forthcoming.

Matt

Hetsr Author

Level 1

0 points

Jun 10, 2009 5:08 AM in response to Matt Broughton

Matt, BDAqua,

I am really (really) appreciative of the time you have you have put into this. I understand that you have limited (spare ?) time to help others and respect how seriously you treat this sort of support.

It is disappointing that we have not been able to support 1.5 inch forms on the Mac OS X / dot matrix combo as it is a common label size. It is a functionality that is important to me and from my readings I assume others.

Regarding your last post (Matt) I have a suspicion the every second form is more to do with the 3" form size set in the printer rather than any sort of driver issue (I noticed it earlier today). Sorry but I'm not going to chase this any further, it has already consumed far to many hours of my time (and yours).

Re the alternative work flow, I used to have this functionality in OS 9 with GDT Powerprint, I had a look but it is no longer available and I suspect that to get any sort of reasonable functionality in OS X would again be very time consuming.

What bothers me more is that I am a very strong advocate of the Mac environment but I was able to get the 1.5 inch form to print from an XP machine in about an hour (but based on what I had picked up through this work). I've still got some work to do but I suspect the work flow may be:
1) Prepare and print the labels in XP / Word (pain)
2) To set up the forms in OS X, print to PDF, then print the PDF from XP
or
3) Share the printer under XP and print to it from OS X

Again, thanks

Hetsr

BDAqua

Level 10

250,259 points

Jun 10, 2009 12:31 PM in response to Hetsr

Thanks, and good luck! 🙂

This thread has been closed by the system or the community team. You may vote for any posts you find helpful, or search the Community for additional answers.

Help with custom page size support for non standard paper