[poppler] DeviceN support in splash

[Thomas Freitag]

Hi,

Am 15.05.2012 09:26, schrieb Thomas Freitag:
> Am 14.05.2012 20:01, schrieb Albert Astals Cid:
>> El Dilluns, 2 d'abril de 2012, a les 07:25:36, Thomas Freitag va 
>> escriure:
>>> Am 30.03.2012 10:57, schrieb Thomas Freitag:
>>>> Hi Albert!
>>>>
>>>> Last weekend I nearly finished the DeviceN support in splash. It runs
>>>> through my regtest, and there are only a few outputs I want to have a
>>>> deeper look into it. If You think there is time left to look into it
>>>> before freeze the actual version, I'll try to finish it this weekend.
>>> This is now the final patch for DeviceN support. It runs successfully
>>> through my regression tests. It has only a few minor changes to the 
>>> beta
>>> patch which are needed to solve a few regressions.
>> Since we are now open for new features in master, can you send a 
>> rebased patch
>> against current master?
> Thanks for the reminder, it's actual the 3rd point on my poppler time 
> schedule:
> 1. The highest priority has a reliable patch for bug 49523, because we 
> should render PDFs again we already could render prior 19.0. I already 
> prepared a new patch, but I need to regtest it. Hopefully I can upload 
> it thursday morning.
Thanks for commiting!
> 2. The next point is the revised blend mode implementation in splash 
> CMYK (also needed for DeviceN)
Just mailed.
>
> 3. Then I'll plan to send a rebased patch for the DeviceN support in 
> splash.
Okay, would be the next point, after You commited patch for point 2 (or 
reject it, but I'm quite sure that this will not be the case). But 
because there is a lot of time went by: Do You think You're able to 
check the patch before releasing 0.22.0? Otherwise I could continue with

1. Enhancement for thin lines (bug #37347)

That patch is much smaller than DeviceN support in splash, but will 
cause a lot of time for regtesting (remember: round about 36 % of output 
will change)

or

2. Make page rendering thread safe (bug #50992)

Also a smaller patch. But here I have another small problem: To test 
that the patch will make page rendering thread safe, I made several 
changes in pdftoppm but only for the windows platform. Of course I could 
do that for unix, too. But do we really need multi threading in 
pdftoppm? In our regtest we already speed it up with starting two 
processes, one for odd and one for even pages. If I now change pdftoppm 
to use multiple threads, it could slow down (I'm not sure, haven't 
tested that, just a guess) our regtest a little bit because of the 
overhead of thread handling on a dual core machine (but definetely will 
speed it up on a quad core machine).
Or should I spend an additional option to use more than one thread?

Cheers,
Thomas

> The following points would be
> 4. A fix for bug 37347 and last but not least
> 5. A patch for bug 49037, if nobody else has the mercy to do it.
>
> Cheers,
> Thomas
>>
>> Cheers,
>>    Albert
>>
>>> Cheers,
>>> Thomas
>>>
>>>> Here a first beta release for the support which I used to create the
>>>> just mailed samples.
>>>>
>>>> Regards,
>>>> Thomas
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> poppler mailing list
>>>> poppler at lists.freedesktop.org
>>>> http://lists.freedesktop.org/mailman/listinfo/poppler
>> _______________________________________________
>> poppler mailing list
>> poppler at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/poppler
>>
>> .
>>
>
>
> _______________________________________________
> poppler mailing list
> poppler at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/poppler
>
> .
>