Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

PDE woes

I am currently struggling with a problem where switching back and forth
between two printer drivers in the Print Dialog will eventually result
in the PDE's not being invoked. i.e. Start with printer A, there are
seven choices. Switch to printer B, there are still seven choices.
Switch back to printer A, only the four standard options are displayed
in the popup.

I have an email thread from this discussion list (around May '03) that
described an identical problem; albeit centered around a syntax error
in PPD files. The two drivers I am working with have no PPD files and
I'm wondering if anyone else has seen a similar error with
non-PostScript printers and if anyone has ideas on how to fix this?

I will paste some of the thread below with apologies for the length.
Thanks in advance...

Bret Kurth
Intriguing Development, Inc.

=======

> From: "John Rice" <email@hidden>
> Date: Fri May 9, 2003 7:23:08 AM US/Central
> To: "List Printing" <email@hidden>, "Paul Danbold"
> <email@hidden>
> Cc: "ezipdev" <email@hidden>
> Subject: Re: PDE not invoked when PPD has syntax error (and sometimes
> not showing up with good PPD)
>
> Paul,
> I will try to be more clear.
>
> We had a client for whom our PDE was not showing up on HP
4000,5000,5100
> printers. We were able to reproduce the problem and discovered that
> the PPDs for these printers had a syntax error, the '*End' in the
> resolution chunk was not capitalized.. ie '*end', further tracking
showed that
> these PPDs were released with 10.2.0 release and HP fixed them in the
10.2.3
> release. The behavior these broken PPDs produced when the print
> dialog was displayed was to not show any PDE options in the popup (
only the 4
> default options are displayed ), our PDE was not being invoked at all
( plugin
> factory instance method not being called ). However, if you switched
> printers ( to a printer with a *good* PPD (not necessarily invoking
our
> PDE) ) and then switched back to the printer with the bad PPD our PDE
> would then be invoked correctly and appear in the PDE popup list.
> Furthermore this behavior only happens when the printer with the bad
PPD is the
> current default ( first printer that shows up when the Print Dialog
is invoked).
> Once the PDE displays correctly it will continue to display correctly
until
> you quit and restart the application.
>
> So... we deduce that when the print dialog is being displayed
> (initialized) for the first time with a particular application and the
> current printer's PPD is being parsed, it spews (throws an exception )
> on the syntax error in the PPD and terminates (bypasses) any more
> processing ( doesn't even attempt to ask what PDEs might want to add
themselves
> into the display for the printer ). Later when the user switches to
another
> printer and comes back the Print Manager has already flagged that the
> PPD has an error so doesn't throw an exception and continues with
normal
> processing asking resident PDEs if they want to display themselves.
>
> The bottom line for us is that we have fixed the above condition
by
> using updated PPDs. However, on rare occasions ( 1, 2 times a day (
> 100+ total print jobs) ), printers for whom the PDE shows up
successfully
> will occastionally display the identical behavior ( PDE doesn't
display,
> only default options are available initially, switching to another
printer
> and coming back displays the PDE ). The only difference is that when
you
> quit the app and restart, the printer will show the PDE successfully
( its
> rare when it fails).
>
> We are hoping that by introducing a syntax error into a PPD you
> could take a look at the PPD parsing/throw logic to validate what we
are
> saying and then tell us under what other circumstances a *good* PPD
would also
> generate this behavior. Because PDE factory instance method is not
> being called we don't think there is a whole lot we can do on our end
to
> remedy this situation.
>
> We have one client with 400 macs printing through Print Center
> 'AppleTalk' configured printers that has never experienced this
> problem (or the users just retry on the rare occasions). The client
who is having
> trouble is predominantly using 'IP Printing' configured printers.
>
> And of course the term 'rare' is subjective, our client considers
> the current 'rare' behavior to be pretty darn close to unacceptable.
>
> thanks in advance...
> John
>
> ----- Original Message -----
> From: "Paul Danbold" <email@hidden>
> To: "John Rice" <email@hidden>
> Sent: Thursday, May 08, 2003 8:13 PM
> Subject: Re: PDE not invoked when PPD has syntax error (and sometimes
> not showing up with good PPD)
>
>> John,
>>
>> To answer this it would help to know what's happening in your PDE.
Do
>> you have any debugging information? Are other PDEs affected?
>>
>> -Paul
>>
>> On Tuesday, May 6, 2003, at 12:49 PM, John Rice wrote:
>>
>>> Greetings,
>>>
>>> We have created a PDE for a CUPS print queue. We have found that if
>>> the PPD file assigned to the queue (called it Queue A) has an error
in it,
>>> AND the queue is the default printer, then our PDE is not called
when the
>>> Print dialog is invoked (ie, it isn't even initialized) - no PDEs
are
>>> loaded at all in fact.
>>>
>>> However, if you switch to another printer (Queue B) and then back to
>>> Queue A, the PDE is loaded.
>>>
>>> Additionally, after pressing cancel (or printing), our PDE is called
>>> for all subsequent invocations of the Print dialog _until the
application is
>>> restarted_.
>>>
>>> Of course, if Queue B is the default printer, then all works fine
when
>>> you switch to Queue A (with the malformed PPD file). It seems that
this
>>> behavior only happens if the PPD file parsing fails the _first_ time
>>> the print dialog comes up in the application.
>>>
>>> To demonstrate this, we took the Generic PPD, created a copy, and
>>> modified it so that the PPD parsing would fail - this is done by
changing one
>>> of the "*End" lines to "*end".
>>>
>>> Can anyone explain this behavior? Is there a way around this?
>>>
>>> The reason this is important is that one of our customers had the
>>> problem, and we traced it to a bad HP PPD file which was fixed by
HP recently.
>>> However, even with this fix the customer appears to be having this
>>> problem once after 100 or so invocations of the Print dialog. Our
suspicion
>>> is that there is something going wrong with the PPD parsing, but we
cannot
>>> figure out why this impacts the loading of our PDE.
>>>
>>> Thanks,
>>>
>>> John Rice
>>> Software Engineer
_______________________________________________
printing mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/printing
Do not post admin requests to the list. They will be ignored.


Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.