ppdi not merging common content from multiple PPDs?

[Smith Kennedy]

On Mar 3, 2009, at 12:08 PM, Michael Sweet wrote:

> On Mar 3, 2009, at 7:49 AM, Smith Kennedy wrote:
>> ...
>> If this is expected behavior (I seem to recall finding in my  
>> thrashing that it is),
>
> It is currently the expected behavior; optimizing the output is on  
> our TODO list but hasn't yet happened.

My mistake - I thought it used to do this some time ago, but I must  
have been mistaken.  Will this be in the DDK included with CUPS 1.4?

>
>> it isn't clear to me what value ppdi is providing.  The primary  
>> value I can see in using the CUPS DDK is the ability to inherit  
>> common elements.  But if those commonalities have to be identified  
>> by hand, because ppdi cannot do it itself, that makes it much more  
>> difficult to adopt the CUPS DDK for PPD development, particularly  
>> if there are already large numbers of existing PPDs that one might  
>> want to import.
>
> That is definitely an issue; one possible path to take is to import  
> the first model in a series and then add sub-blocks for each  
> variation - in my experience most new models are almost identical to  
> their predecessors.
>
>> I thought the problem might be that the files were not  
>> "normalized", so tried importing one using ppdi and then re- 
>> generating it using ppdc, and did the same thing for the second  
>> one.  Interestingly, ppdi refused to import the ppds generated by  
>> ppdc.
>
> What errors did you see?

There were no errors written out to stdout or stderr.  Here is an  
example run I did just now:

smitty at tibook Resources$ pwd
/Library/Printers/PPDs/Contents/Resources
smitty at tibook Resources$ gzcat hp\ LaserJet\ 1300\ series.gz > hp\  
LaserJet\ 1300\ series
smitty at tibook Resources$ ls hp\ LaserJet\ 1300\ series*
hp LaserJet 1300 series		hp LaserJet 1300 series.gz
smitty at tibook Resources$ ppdi hp\ LaserJet\ 1300\ series
smitty at tibook Resources$ ppdc -d . ppdi.drv
smitty at tibook Resources$ ls *1300*
HP Deskjet D1300 series.ppd.gz	hp LaserJet 1300 series.gz
hp LaserJet 1300 series		hp1300_6.ppd
smitty at tibook Resources$ ppdi -o new.drv hp1300_6.ppd
smitty at tibook Resources$ ls -l *.drv
-rw-r--r--  1 smitty  admin     102 Mar  3 15:10 new.drv
-rw-r--r--  1 smitty  admin  128348 Mar  3 15:09 ppdi.drv
smitty at tibook Resources$ cat new.drv
// CUPS PPD Compiler v1.2.3

// Include necessary files...
#include <font.defs>
#include <media.defs>
smitty at tibook Resources$

Notice that there were no error messages written out by ppdi when  
importing hp1300_6.ppd.  But the "new.drv" file doesn't have the  
LaserJet 1300 in it.  I checked system.log and the console log in  
Console.app on Mac OS X and didn't see anything.

>
>> My questions are these:
>> 1) did ppdi used to be able to do this inheritance analysis  
>> itself?  If so, why was it removed?
>
> ppdi has never done any optimization on the generated .drv file.
>
>> 2) regardless of past history, can ppdi be fixed to do this?
>
> Yes, the key issue is implementing the optimizations efficiently. A  
> 1-level pass (just put all of the common stuff at the top and only  
> encode differences in sub-blocks) should be fairly easy and quick,  
> but doing multiple levels is tricky.

Hand-editing is tricky, which is why I was hoping to use the tool.  :-)

Perhaps a 1-level pass would be possible as a first-phase enhancement  
that could make it into 1.4, with multi-level implemented later?

>
>> 3) why won't ppdi import a ppd created by ppdc from another database?
>
> I don't know, it certainly should!  Again, any errors?
>
>> 4) What workflow was envisioned for the CUPS DDK?  Am I just using  
>> it improperly?
>
> The DDK (and in particular the PPD compiler) has always been  
> primarily a PPD creation tool. Importing existing PPDs is supposed  
> to be a one-time thing, after which you just work with the drv and  
> po/strings file(s).
>
> ________________________________________
> Michael R Sweet, Senior Printing System Engineer
>
> <ATT00001.txt>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cups.org/pipermail/cups/attachments/20090303/212c14a1/attachment.html>