Windows printing to HP 4014N from filePro
John Esak
john at valar.com
Wed Jul 21 09:59:38 PDT 2010
Good luck,
And I knew you knew all this stuff, but wasn't sure if I was writing to the
customer or you...
John
> -----Original Message-----
> From: filepro-list-bounces+john=valar.com at lists.celestial.com
> [mailto:filepro-list-bounces+john=valar.com at lists.celestial.co
> m] On Behalf Of Steve Wiltsie
> Sent: Wednesday, July 21, 2010 8:28 AM
> To: filePro Mailing List
> Subject: RE: Windows printing to HP 4014N from filePro
>
> John,
>
> First, thanks for your detailed note.
>
> Please notice that the subject of my original e-mail was "SCO printing
> to HP 4014N from filePro". Somewhere along the line someone
> changed it
> to what you see above. I did not do this. I know the difference
> between printing from Windows and printing from SCO
> OpenServer 5. Since
> this customer has both an SCO OpenServer system and a Windows 2003
> server, I did change the print driver on the Windows server just to be
> sure the first one wasn't leaving the printer in a state that was not
> overcome by the SCO printer interface script and filePro print codes.
> This had no effect on either system's printing.
>
> The printer interface script on the SCO system I have been
> using for the
> printer at this IP address has not changed. It has worked as
> needed for
> 15 or so years. It was only the introduction of this new printer that
> seemed to have caused this rather bizarre behavior - the same SCO
> filePro print job that is properly formatted when it prints
> from tray 1
> is not properly formatted when it prints from tray 2. It is
> not the SCO
> interface script or a filePro print code that is choosing the
> tray. The
> printer is set to print from tray 1 if there is paper in it.
> Simple as
> that. If tray 1 is empty and/or closed, the printer prints
> from tray 2
> (the built-in tray that pulls out to load paper). This is as designed
> and I have no problem with that.
>
> I am well aware of Jim's handiwork with filePro and other printing and
> have used him to develop special forms for my customers several times
> over the years. (I even have his phone number).
>
> filePro support did send me some suggestions about this issue
> but, like
> some others, were under the impression I was trying to select
> trays with
> print codes. However, I appreciated them contacting me about
> the issue.
>
> HP tech support was totally unhelpful on this. They simply
> didn't have
> any clue as soon as I said "Unix".
>
> The customer did tell me something new yesterday, however,
> and I'm going
> to be on-site later today to check it out.
>
> Thanks,
> Steve Wiltsie
>
>
> -----Original Message-----
> From: John Esak [mailto:john at valar.com]
> Sent: Tuesday, July 20, 2010 9:27 PM
> To: Steve Wiltsie; 'filePro Mailing List'
> Subject: RE: Windows printing to HP 4014N from filePro
>
> Steve,
>
> 1)
> First, your best bet is to contact Jim Asman and enlist his aid. Your
> problem will be diagnosed and solved quicker than you can imagine. Jim
> will
> read this note because he follows the list...and he might give some
> "real"
> advice... But I would contact him at jlasman at telus.net and ask for his
> phone
> number. I could provide it of course, but we haven't ever
> done that here
> in
> 30 years, no need to start now.
>
> 2)
> I will make some hopefully helpful comments. Whatever the
> problem is, it
> will NOT be solved with a PCL6 driver. I'm a little unclear as to
> whether
> you're working in Unix/SCO or windows... But if your old 2015 worked
> fine,
> you were most likely using PCL5. In both cases even though on Windows
> it's
> called a "driver" and on SCO it is not at all that but just
> an interface
> file which filters and adds some simple formatting codes. They both
> don't
> really "do" anything. All the commands in PCL5 are just
> simple character
> strings usually starting with an ESC and ending with a particular
> pattern.
> Combine all these sequences and you get your document sent to the
> printer
> which follows all the plain ascii commands and builds your
> output. This
> is
> sent to the printer which rasterizes it all into one big page feed and
> prints it. All this "blather" to say this next thing.
>
> 3)
> The trays and the order of printing is stored as choices and
> preferences
> in
> the printer itself. You can send codes to pick one tray over another,
> but
> lots of the preferences stored in the printer still hold
> sway. In other
> words, you may have it set up to accept printouts in the top tray, but
> if
> the printer finds that tray empty, it might look for another tray that
> has
> been assigned the same "paper type" like "letterhead". If no tray is
> assigned to print the same kind of paper as the empty tray, nothing is
> printed even though three other trays are full of paper. The printer
> thinks
> it's the wrong kind.
>
> 4)
> Obviously, I'm getting into lots of strange and maybe unhelpful stuff,
> but
> this I'm sure. The problem is NOT in the "driver". ON Windows you want
> to be
> using something that doesn't muck up your designated codes from a PCL5
> type
> printer table, and on Windows, the same applies, but you MUST
> use a PCL5
> driver. The PCL6 driver does not interpret the filePro PCL5 print code
> table
> commands. It tries to build an image and sends this to an essentially
> dumber
> printer. The older printer you had was built with enough smarts to
> decode
> the stuff from filePro and a clear driver and build the final page
> itself in
> its own innards. So, this is why I think the strange behavior is
> external
> to all the stuff coming from the outside world. It is a setting that
> needs
> to be fiddled with to get proper operation.
>
> I know Jim has dealt with this issue on other HP printers. As long as
> you
> continue to use strict PCL5 all the way to the printer, and
> not move to
> PCL6
> for any reason. You will I'm sure end up getting the same
> behavior from
> the
> new printer as the old. What amazes me is that the HP tech couldn't
> help.
> They usually don't get baffled when they hear the word Unix
> or SCO, but
> filePro thrown into the mix and something called a filePro printcode
> table
> mess them up pretty good. They start thinking it's something outside
> their
> ken... And it really isn't.
>
> Jim sounds great on the phone and is slowly getting over his
> near-death
> (no
> lie) experience.
>
> Good luck.
>
> John
>
>
>
>
>
>
> > -----Original Message-----
> > From: filepro-list-bounces+john=valar.com at lists.celestial.com
> > [mailto:filepro-list-bounces+john=valar.com at lists.celestial.co
> > m] On Behalf Of Reggie Freedman DC1
> > Sent: Tuesday, July 20, 2010 5:15 PM
> > To: Steve Wiltsie; filePro Mailing List
> > Subject: Windows printing to HP 4014N from filePro
> >
> >
> > Since filePro has an HP PCL5 driver to use...
> > On my Windows Server(s), I always create a generic
> > printer, i.e., no codes, so what is sent from filePro
> > is passed through to the printer without added
> > 'flavoring'. For different printers, I add another
> > generic printer, no codes, in Windows Server.
> >
> > Reggie
> >
> >
> > ----- Original Message -----
> > From: "Steve Wiltsie" <swiltsie at micro-mui.com>
> > To: "filePro Mailing List" <filepro-list at lists.celestial.com>
> > Sent: Monday, July 19, 2010 5:08 PM
> > Subject: SCO printing to HP 4014N from filePro
> >
> >
> > >I have something I don't think I've seen before going on with a new
> > > LaserJet 4014N at a customer site. They recently
> replaced an old HP
> > > 2015N that had failed with this new 4014N. We can print to
> > it just fine
> > > from Windows with either the PCL5 or PCL6 drivers from HP.
> > The printer
> > > has the latest firmware installed. The SCO HPLaserJet
> > driver is still
> > > the one we have used with the 2015N, so that hasn't changed.
> > >
> > > My problem is this: if the drop-down tray 1 is open and
> > has paper in
> > > it, filePro print jobs will print properly with pitch,
> orientation,
> > > lines per inch, whatever, from that tray. If that tray is
> > closed, the
> > > print jobs will come out WITHOUT ANY FORMATTING from the
> > standard tray
> > > 2.
> > >
> > > To fix this I've switched from PCL5 to PCL6 drivers on the Windows
> > > server to make sure that Windows printing wasn't leaving
> > the printer in
> > > a state that Unix couldn't overcome but that didn't help. We have
> > > rebooted Unix and the printer to clear everything but that
> > didn't help.
> > > I have updated the printer's firmware.
> > >
> > > I've been on the phone with HP tech support who couldn't
> help me and
> > > sent me to an Active Chat who couldn't help me and sent me
> > to a phone
> > > number that turned out to be 'contract support' who
> > couldn't help me and
> > > sent me back to standard support who kept suggesting that
> > we re-download
> > > the PCL6 drivers for Windows. So they weren't too much
> > help in addition
> > > to being hard to understand.
> > >
> > > That's why I'm turning to this group. Has anyone seen this issue
> > > before? If so, what did you do to fix it?
> > >
> > > Thanks,
> > > Steve Wiltsie
> > >
> > > -------------- next part --------------
> > > An HTML attachment was scrubbed...
> > > URL:
> > >
> > http://mailman.celestial.com/pipermail/filepro-list/attachment
> > s/20100719/37b33c5d/attachment.html
> > > _______________________________________________
> > > Filepro-list mailing list
> > > Filepro-list at lists.celestial.com
> > > http://mailman.celestial.com/mailman/listinfo/filepro-list
> >
> > _______________________________________________
> > Filepro-list mailing list
> > Filepro-list at lists.celestial.com
> > http://mailman.celestial.com/mailman/listinfo/filepro-list
> >
>
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> http://mailman.celestial.com/mailman/listinfo/filepro-list
>
More information about the Filepro-list
mailing list