[poppler] Fwd: splashModeDeviceN8 in two switch

[Adam Reichold]

Hello again,

Am 25.04.19 um 07:44 schrieb Thomas Freitag:
> Sorry, i wanted to send it to the list, too
> 
> ---------- Forwarded message ---------
> Von:Thomas Freitag <thomas.freitag.bbr at gmail.com>
> Date: Do., 25. Apr. 2019, 07:42
> Subject: Re: [poppler] splashModeDeviceN8 in two switch
> To: Albert Astals Cid <aacid at kde.org>
> 
> 
> Your argument is wrong, Albert.
> Even if we remove the compiler directive, "noone" will use this mode by
> default, because the default rendering is RGB. So you don't need more
> memory for rendering and it doesn't become slower. Just the code need more
> memory.

But sizeof(SplashColor) == 8 instead of 4, then allocating
SplashColor[size] will consume twice the memory even if we only use the
first half of entry, will it not?

Best regards,
Adam

> But the "professionell" user would have the ability to simulate overprint.
> As far as i remember i implemented an overprint option in pdftoppm for this
> purpose. You can see the difference if you run the ghent test suite with
> and without this switch.
> 
> Cheers,
> Thomas
> 
> PS: Not only William uses it, i do it too
> 
> Albert Astals Cid <aacid at kde.org> schrieb am Mi., 24. Apr. 2019, 19:40:
> 
>> El dimarts, 23 d’abril de 2019, a les 18:11:04 CEST, Adam Reichold va
>> escriure:
>>> Hello,
>>>
>>> thinking about this again with a bit of distance, should we maybe remove
>>> the `SPLASH_CMYK` preprocessor flag entirely? I am assuming the reasons
>>> for having this upstream is to keep the code from bit rotting as
>>> Poppler's internals change? If nobody builds this, then this will not
>>> happen. (CI checks improve things, but it will still be "late" feedback
>>> instead of being part of the initial edit-compile-test cycle. Also, this
>>> will not reach e.g. clusterfuzz which thereby will not verify that code.)
>>>
>>> Are there any downsides to removing the conditional compilation? Does
>>> this break code that does not request the CMYK handling explicitly? If
>>> so, could we fix this via the internal API instead of hard-coded it at
>>> compile time?
>>
>> The main problem i see is that it makes SplashColor for from 4 bytes to 8
>> bytes, so may make things slower/use more memory for a feature "noone uses".
>>
>> Cheers,
>>   Albert
>>
>> P.S: Of course the "noone uses" is a bit of a self fulfilling prophecy if
>> we don't enable it
>>
>>>
>>> Best regards,
>>> Adam
>>>
>>> Am 22.04.19 um 13:14 schrieb Albert Astals Cid:
>>>> This is mostly for William since AFAIK he's the "only" one using
>> SPLASH_CMYK.
>>>>
>>>> I've tried to enable SPLASH_CMYK on the CI and it's loudly complaining
>> that the splashModeDeviceN8 cases are missing in SplashOutputDev.cc
>>>>
>>>> https://gitlab.freedesktop.org/aacid/poppler/-/jobs/253647
>>>>
>>>> Any suggestion of what the code should be?
>>>>
>>>> Should they just be the same as case splashModeCMYK8: ? The first one
>> looks like it may make sense, but not so sure about the second.
>>>>
>>>> Cheers,
>>>>   Albert
>>>>
>>>>
>>>> _______________________________________________
>>>> poppler mailing list
>>>> poppler at lists.freedesktop.org
>>>> https://lists.freedesktop.org/mailman/listinfo/poppler
>>>>
>>>
>>>
>>
>>
>>
>>
>> _______________________________________________
>> poppler mailing list
>> poppler at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/poppler
> 
> 
> _______________________________________________
> poppler mailing list
> poppler at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/poppler
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/poppler/attachments/20190425/710ba95d/attachment.sig>