<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div><div><div>On Mar 3, 2009, at 12:08 PM, Michael Sweet wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On Mar 3, 2009, at 7:49 AM, Smith Kennedy wrote:</div><blockquote type="cite"><div><font class="Apple-style-span" color="#000000">...<br></font>If this is expected behavior (I seem to recall finding in my thrashing that it is), </div></blockquote><div><br></div>It is currently the expected behavior; optimizing the output is on our TODO list but hasn't yet happened.</div></div></blockquote><div><br></div>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?</div><div><br></div><div><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><br><blockquote type="cite"><div>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.<br></div></blockquote><div><br></div>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.</div><div><br><blockquote type="cite"><div>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.<br></div></blockquote><div><br></div>What errors did you see?</div></div></blockquote><div><br></div><div>There were no errors written out to stdout or stderr. Here is an example run I did just now:</div><div><br></div><div><div></div><div>smitty@tibook Resources$ pwd</div><div>/Library/Printers/PPDs/Contents/Resources</div><div>smitty@tibook Resources$ gzcat hp\ LaserJet\ 1300\ series.gz > hp\ LaserJet\ 1300\ series</div><div>smitty@tibook Resources$ ls hp\ LaserJet\ 1300\ series*</div><div>hp LaserJet 1300 series<span class="Apple-tab-span" style="white-space: pre; "> </span>hp LaserJet 1300 series.gz</div><div>smitty@tibook Resources$ ppdi hp\ LaserJet\ 1300\ series</div><div>smitty@tibook Resources$ ppdc -d . ppdi.drv </div><div>smitty@tibook Resources$ ls *1300*</div><div>HP Deskjet D1300 series.ppd.gz<span class="Apple-tab-span" style="white-space: pre; "> </span>hp LaserJet 1300 series.gz</div><div>hp LaserJet 1300 series<span class="Apple-tab-span" style="white-space: pre; "> </span>hp1300_6.ppd</div><div>smitty@tibook Resources$ ppdi -o new.drv hp1300_6.ppd </div><div>smitty@tibook Resources$ ls -l *.drv</div><div>-rw-r--r-- 1 smitty admin 102 Mar 3 15:10 new.drv</div><div>-rw-r--r-- 1 smitty admin 128348 Mar 3 15:09 ppdi.drv</div><div>smitty@tibook Resources$ cat new.drv </div><div>// CUPS PPD Compiler v1.2.3</div><div><br></div><div>// Include necessary files...</div><div>#include <font.defs></div><div>#include <media.defs></div><div>smitty@tibook Resources$ </div><div><br></div><div>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.</div><div><br></div></div><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><br><blockquote type="cite"><div>My questions are these:<br>1) did ppdi used to be able to do this inheritance analysis itself? If so, why was it removed?<br></div></blockquote><div><br></div>ppdi has never done any optimization on the generated .drv file.</div><div><br><blockquote type="cite"><div>2) regardless of past history, can ppdi be fixed to do this?<br></div></blockquote><div><br></div>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.</div></div></blockquote><div><br></div>Hand-editing is tricky, which is why I was hoping to use the tool. :-)</div><div><br></div><div>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?</div><div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><br></div><div><blockquote type="cite"><div>3) why won't ppdi import a ppd created by ppdc from another database?<br></div></blockquote><div><br></div>I don't know, it certainly should! Again, any errors?</div><div><br><blockquote type="cite"><div>4) What workflow was envisioned for the CUPS DDK? Am I just using it improperly?<br></div></blockquote><div><br></div><div>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).</div><div><br></div><div><span class="Apple-style-span" style="font-family: Helvetica; ">________________________________________</span></div></div><div><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Monaco; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>Michael R Sweet, Senior Printing System Engineer</div></div></div></span></span> </div> <br><span><ATT00001.txt></span></div></blockquote></div><br></div></div></body></html>