[poppler] GfxState::shiftCTM

[Thomas Freitag]

Am 26.01.2013 13:56, schrieb Albert Astals Cid:
> El Dissabte, 26 de gener de 2013, a les 20:40:14, 王璐 va escriure:
>> Hi all,
>>
>>     In GfxState.h, this function is declared right after setCTM and
>> concatCTM, which looks like no big deal than the other 2, but actually also
>> modifies clip BBox of the State
>>
>>     The only place this function is used is in the functions handling
>> transparency groups in SplashOutputDev.cc. I'm not familiar with that part,
>> but looks like an ad hoc hack.
>>
>>     I found this while I want to track all functions that might update clip
>> BBox, this does not make sense to me. Although I've got no better solution,
>> at least it might be more reasonable if we add a new backdoor for clip BBox
>> and change shiftCTM to what it looks like. In this way SplashOutputDev
>> still takes the responsibility, but GfxState is relieved.
>>
>>     What do you think ? I can create a patch.
> Why do you think this is a problem?
>
>
> To be honest i don't see any need for a change, all these functions are
> internal and not supposed to be used outside the inner world of poppler
> itself, so the function is doing what it should do.
>
> At most we could rename the function, and name it something like
> shiftCTMAndClip or something, would that work for you?
It's definitely needed in SplashOutputDev: SplashOutputDev creates a new 
bitmap for transparency groups and has to shift the CTM so that Gfx 
continues drawing in that new bitmap with changed origin and not outside 
it. I see neither a need need to create a backdoor which makes it more 
unreadable nor to rename it, even it it changes the clipping as side 
effect, but that should be expected when someone shifts the current 
transfer matrix.

Cheers,
Thomas
>
> Cheers,
>    Albert
>
>>     regards,
>>     - Lu
> _______________________________________________
> poppler mailing list
> poppler at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/poppler