BBox rect 'appears' off for shading and clip paths

[qwertynik]

@JorjMcKie
From our earlier conversations, based on the info you shared, it is clear that the output shown for page.get_bboxlog or page.get_drawings is influenced by the output of mutool trace command. In the mutool trace command the output appears to be correct. But the output of bbox log looks off for fill_shade paths

mutool trace output:

<document filename="pdfs/PHT44.pdf">
    <page number="1" mediabox="0 0 648 1296">
        <set_default_colorspaces gray="DeviceGray" rgb="DeviceRGB" cmyk="DeviceCMYK" oi="None"/>
        <clip_path winding="eofill" transform="1 0 0 -1 0 1296">
            <moveto x="233.409" y="1174.43"/>
            <lineto x="423.517" y="1174.43"/>
            <lineto x="423.517" y="1105.4451"/>
            <lineto x="233.409" y="1105.4451"/>
            <closepath/>
        </clip_path>
        <fill_path winding="eofill" colorspace="DeviceRGB" color=".282353 .690196 .458824"
                   transform=".49827 0 0 -.423888 194.942 100.81995">
            <moveto x="0" y="0"/>
            <lineto x="517.42" y="0"/>
            <lineto x="517.42" y="-256.03"/>
            <lineto x="0" y="-256.03"/>
            <closepath/>
        </fill_path>
        <stroke_path linewidth="1" miterlimit="10" linecap="0,0,0" linejoin="0" colorspace="DeviceRGB"
                     color=".498039 .498039 .498039" transform=".49827 0 0 -.423888 194.942 100.81995">
            <moveto x="0" y="0"/>
            <lineto x="517.42" y="0"/>
            <lineto x="517.42" y="-256.03"/>
            <lineto x="0" y="-256.03"/>
            <closepath/>
        </stroke_path>
        <pop_clip/>
        <clip_path winding="eofill" transform="1 0 0 -1 0 1296">
            <moveto x="215.157" y="821.678"/>
            <lineto x="430.557" y="821.678"/>
            <lineto x="430.557" y="725.678"/>
            <lineto x="215.157" y="725.678"/>
            <closepath/>
        </clip_path>
        <clip_path winding="eofill" transform="1 0 0 -1 0 1296">
            <moveto x="227.03" y="814.189"/>
            <lineto x="420.961" y="814.189"/>
            <lineto x="420.961" y="734.07907"/>
            <lineto x="227.03" y="734.07907"/>
            <closepath/>
        </clip_path>
        <fill_shade alpha="1" transform="1.10123 0 0 -1.09589 -222.911 1387.637" pattern_matrix="1 0 0 1 0 0"
                    colorspace="DeviceRGB" type="linear" extend="1 1" start="415.504 778.155" end="616.504 778.155"/>
        <pop_clip/>
        <pop_clip/>
        <clip_path winding="eofill" transform="1 0 0 -1 0 1296">
            <moveto x="226.864" y="1009.63"/>
            <lineto x="420.646" y="1009.63"/>
            <lineto x="420.646" y="935.526"/>
            <lineto x="226.864" y="935.526"/>
            <closepath/>
        </clip_path>
        <fill_shade alpha="1" transform=".990702 0 0 -.845933 -167.238 991.374" pattern_matrix="1 0 0 1 0 0"
                    colorspace="DeviceRGB" type="linear" extend="1 1" start="415.504 778.155" end="616.504 778.155"/>
        <pop_clip/>
    </page>
</document>

Any ideas why? Or mutool trace command itself gives such an output?

[JorjMcKie]

Shading is unsupported by .get_drawings() and by the .draw_*() methods.

[qwertynik]

Yes, aware of the same from our earlier conversation and from the Note in the documentation.

[JorjMcKie]

• The bboxlog rectangles are sometimes a bit larger than expected.
• If clips are present (as is the case here) the result may be influenced in an unforeseen way, because PyMuPDF ignores clips altoghether.

[qwertynik]

Can you share your notes, if any, on the complexity of dealing with shading and clips? Will help in understanding PDFs and PyMuPDF better.

[qwertynik]

@JorjMcKie

[JorjMcKie]

I have no such things. Best look at the PDF spec on this topic.

[qwertynik]

@JorjMcKie
Had noted the same for other text BBoxes as well - they are larger than expected. Is there a way to get the containing box information based on how the objects visually appear to the human eye?

[JorjMcKie]

No.

[qwertynik]

@JorjMcKie Ok. Clipping paths and other PDF authoring tools might make it complex. In addition to removing the clipping path and surrounding whitespace in bbox, is there anything else that should be done so as to get the visual bounding box for pdf objects? Wanting to understand the challenges in implementation that PyMuPDF would have faced and also improve my understanding of the PDF format.

[JorjMcKie]

Best look at MuPDF's C code, specifically mupdf-1.19.0/source/fitz/bbox-device.c. That is where my respective code was derived from.

[qwertynik]

Thanks for pointing @JorjMcKie will check.