[poppler] GfxState::shiftCTM

[王璐]

But setCTM and concatCTM does not change clipping.
In PDF, once a clipping path is set, further changes of CTM do not change
the clipping path, right?

>From the name, shiftCTM looks like a shortcut for concatCTM(1,0,tx,0,1,ty),
but it does more. That's why I'm saying it's confusing.


My suggestion is to rename it, or add a new statement
"state->clip_backdoor(tx,ty)" right after when shiftCTM is called.


regards,
- Lu


On Sat, Jan 26, 2013 at 9:37 PM, Thomas Freitag <Thomas.Freitag at kabelmail.de
> wrote:

> 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<http://lists.freedesktop.org/mailman/listinfo/poppler>
>>
>
>
> ______________________________**_________________
> poppler mailing list
> poppler at lists.freedesktop.org
> http://lists.freedesktop.org/**mailman/listinfo/poppler<http://lists.freedesktop.org/mailman/listinfo/poppler>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/poppler/attachments/20130126/f97f50a9/attachment.html>