Closed lbschenkel closed 1 year ago
Hey there @lbschenkel !!
You can try using the following command to print specifically in 600 dpi:
lp -o media= <Page Size> -o resolution=600dpi FILENAME
Here <Page Size>
can be replaced with A4 or any page dimension as needed.
Also I think the algorithm behaviour is expected. A resolution entry can only be nullified if either the resolution list entry is missing or if it contains broken entries.
In your case it might be the second case due to which the following command gets executed:
goto bad_ppd;
The function bad_ppd
is as follows:
bad_ppd:
if (common_res) cupsArrayDelete(common_res);
if (common_def) free(common_def);
if (min_res) free(min_res);
if (max_res) free(max_res);
...
return (NULL);
Here the 600 dpi quality gets referenced as bad ppd due to which the current is deleted and next is taken as default.
Further code can be referred to in the following directory : Cups/PPD
Hope this helps :+1: !
@CodingWarrior33 you cannot force a job to get printed in a resolution not listed in the PPD file. Specifying such a resolution on the command line does not change anything, the option will get ignored and the printer will print with 300 dpi or 1200 dpi.
We have a bug in the code of the PPD generator (file ppd/ppd-generator.c
in the source code of cups-filters). You need to find out what is wrong in the code.
@tillkamppeter with the implementation of commit 808f439f73b947eb1b376e2c3d5c576e445de543 does this issue still remain relevant as the file being referenced has been moved to libppd and the repository has been labelled as legacy ?
Yes, it is still relevant, as even libppd being legacy, we still fix bugs in it.
I have moved it to libppd now.
We have a bug in the code of the PPD generator (file ppd/ppd-generator.c in the source code of cups-filters). You need to find out what is wrong in the code.
Sorry, I'm confused about "what's wrong in the code": the algorithm starting at https://github.com/OpenPrinting/libppd/blob/master/ppd/ppd-generator.c#L612 seems to be clear — if Apple raster is supported, it only takes the lowest and highest resolutions, and ignores anything in between. I'm not quite sure what is the reasoning behind this and why it is only done for Apple raster.
Given that you said "we have a bug in the code" I'm assuming that you agree that the generated PPD, given the published printer attributes, is sub-optimal. It makes no sense to me to have 3 quality profiles and only use 2 resolutions from the printer attributes (worse: ignoring the printer's "best" resolution in terms of tradeoff toner/quality/speed).
In my naïve thinking I would assume that the PPD's draft/normal/high quality profiles should map to the printer's lowest/default/highest resolutions in most circumstances.
@lbschenkel the reasoning behind only taking the lowest and the highest resolution from the resolutions in urf-supported is that perhaps neither @michaelrsweet nor me ever have seen an urf-supported entry with three resolutions. The original code of the PPD generator comes from @michaelrsweet and I have overtaken it, assuming that he knows urf-supported, with so many years working at Apple ... So now the bug is spotted, the PPD generator only supports urf-supported with two resolutions. This piece of code needs to get fixed, to support any number of resolutions, ideally taking the highest resolution for high quality, the lowest resolution for draft quality and the "middle" one for normal quality. If the number of resolutions is odd, it is clear, if it is even, we should "round down", for example taking the first entry of two available ones. @CodingWarrior33 could you do this fix?
@tillkamppeter: it makes some historical sense, yes.
I actually see 2 issues:
ideally taking the highest resolution for high quality, the lowest resolution for draft quality and the "middle" one for normal quality.
This is sensible and would be my choice as well, but perhaps even better is picking printer-resolution-default
for the normal quality profile, assuming it is among the available resolutions and it is > lowest and < highest (in order to avoid "duplication" of quality profiles).
@tillkamppeter @lbschenkel what I understand is that I need to implement a resolution array. 1.The resolution array if having odd length can take resolutions as mentioned by taking highest, middle and lowest. 2.For even length the array will have to choose between 2 profiles (preferably the lower one) as there is no perfect "middle" for an even entry. 3.If lesser usable resolutions are available then we should consider revising the profiles to only draft/default(normal) as there are lesser supported resolutions to avoid duplication. 4.The printer-default resolution should be always preferred over others.
@tillkamppeter : Agree with all the points, this is what I was suggesting as well (perhaps poorly phrased).
Trying to phrase it better:
Regarding point 4, if the algorithm is if(default > lowest && default < highest && default in [resolutions]) then normal = default
then you're also potentially addressing points 1 and 2. Points 1 and 2 then became the fallback algorithm in case the aforementioned test is false
.
This fallback algorithm could also be picking the highest resolution that is <= (lowest + highest)/2. That is closest to the middle of the road, so to speak, and then also becomes indifferent to even/odd number of elements or an uneven distribution of resolutions in the list.
Yes, so we will do:
printer-default-resolution
and this resolution is in the list, use it. If not, use the "middle" one, rounding down if the number of available resolutions is even.Yes, so we will do:
- Draft Quality: Lowest resolution
- High Quality: Highest resolution
- Normal Quality: If there is
printer-default-resolution
and this resolution is in the list, use it. If not, use the "middle" one, rounding down if the number of available resolutions is even.- Duplicate resolutions are no problem, at least if there are other things which also get changed by the print quality.
@tillkamppeter @lbschenkel this sums it up and to add to above mentioned we still keep duplicate resolutions unless there is an effect on print quality due to other factors.
@tillkamppeter @lbschenkel this sums it up and to add to above mentioned we still keep duplicate resolutions unless there is an effect on print quality due to other factors.
Understood, although if you look at the PPD I posted in my printer the quality is only affecting resolution, and nothing else.
Ok, will work on the above stated points.
Sorry to hijack this for an off-topic question, but: does it still make sense to have two separate PPD generators: "ippeve.ppd" and "drvless.ppd"? I understand why that was necessary when CUPS was under Apple stewardship, but now that CUPS became an OpenPrinting project, shouldn't both be unified?
The reason why cups-filters had and now libppd has its own PPD generator is the fact that it is used by cups-browsed to generate PPDs for a cluster of different printers. This needed adaptations in the PPD generator and therefore I was not able to re-merge the CUPS one and the libppd one. Now the PPD generators will fade away with the demise of PPD file use in the general printing workflow and therefore the effort of trying to re-merge them is not worth it any more. cups-browsed will later on be turned into a Printer Application for clustering and adapting to old enterprise distros (with CUPS <= 1.5.x) and so it will not need the PPD generator any more. CUPS will not contain its own PPD generator any more starting with version 3.0. So there stays a single PPD generator in libppd and probably I can deprecate this one right away (to go away in libppd3) as the legacy task of libppd is reading and understanding/converting to IPP attributes PPD files, not creating them.
Fixed by Pull Request #3 from @Kappuccino111. Thanks a lot.
What version of CUPS will this be included in, so I can test?
@lbschenkel The fix is not done in CUPS but in libppd, a part of cups-filters. If you are using a Linux distribution with cups-filters 1.x I could backport the fix to cups-filters.
I use Debian and Arch, so I would appreciate if you could backport this to cups-filters.
@lbschenkel There is a backport of this fix into cups-filters 1.x now:
https://github.com/OpenPrinting/cups-filters/pull/515
Could you try it out?
I'm using
driverless
to generate a PPD for my Brother MFC-L2730DW laser printer (debug output included at the bottom).The printer publishes the following attributes:
Given the above I was expecting the 3 quality profiles to be 300/600/1200 with a default of 600. But the PPD generated by driverless contains:
I have read the code and my understanding of the implementation is that:
Is this the intended behaviour in such a scenario? I would argue that, given the attributes above, anything which is not 300/600/1200 can be surprising behaviour to the user. It basically collapses the 3 quality profiles into 2.
In particular, would it be possible to elaborate as to why the algorithm determining the resolution choices for URF only picks the worst/best resolutions and ignores everything in between?