About get_drawing function

[Yichen-fqyd]

Hello!

When I was using the get_drawing method, sometimes it took several seconds for a page, as to the whole file with 100 pages, it could cost a lot of time.

Any suggestions?

Thank you

[JorjMcKie]

Any suggestions?

Not really. I bet you are talking of pages with an awful lot of drawing commands.
I based the method on a subset of MuPDF's tracing device, which does all the analysis of the painting commands. Its output I then convert to Python objects.
To confirm, try the following command yourself (Windows version), which puts the trace device's output on a text file: mutool trace file.pdf n > file.xml where n is the desired page number (1-based). The output format is XML.

[Yichen-fqyd]

Thanks, I will try this method

[JorjMcKie]

The only choice you have is a ridiculous one: omit the large pages - the amount of time needed should scale with the amount of data processed, which in first approximation is proportional to len(page.read_contents()).

[Yichen-fqyd]

Hello,

I found other weird pdfs about the drawing, does drawing have any scale or direction? When I was visualize the drawing on the pdf page, the drawing doesn't match with the original pdf, seems it is upside down, I am wondering why this pdf is special? I tried to put all points upside down, but the scale is off.

Thank you so much,

[JorjMcKie]

First of all, the method is now a lot faster: page.get_drawings() should be faster by factor 3 or more.
If you are able to use page.get_cdrawings() instead, then you can get along with 10% of the earlier exec time.

Second:
You are not clear about what you have been doing here. It looks like you apply the extracted drawings to the same page again ... in blue??

If so, you probably have that old problem, that the page geometry has been carelessly set: Execute page.clean_contents() right after loading the page and see if you have an improvement.

[Yichen-fqyd]

Wow, this is amazing, I did apply the extracted drawings to the same page again ... in blue, just trying to visualize the drawing part in pdf and never expected the result, after page.clean_contents() everything looks right. Does this mean all the drawing operations I applied messed up the page geometry, which is the reason why it happened?

[JorjMcKie]

Please read this for an explanation.

Does this mean all the drawing operations I applied messed up the page geometry, which is the reason why it happened?

No, it is not your fault. The creator of the PDF was sloppy, that's all.

[JorjMcKie]

@Yichen-fqyd - question:
Are you using the current version 1.18.17? If yes, did you experience performance improvements?

[JorjMcKie]

As I wrote: the best performance can be achieved with page.get_cdrawings(). As the name indicates, it is written in C. The output is very similar to page.get_drawings() - which is based in that C version.
The difference in the C version is that it only contains point-like, rect-like and quad-like tuples - where the page.get_drawings() version contains Point, Rect or Quad objects.

[Yichen-fqyd]

I am using the 1.18.5 currently, let me do the test for the performance,

[JorjMcKie]

You need to upgrade to 1.18.17.
Then a few adjustments are required, because things are returned somewhat differently:

• best use page.get_cdrawings()
• then when evaluating the items of each path, use this logic:

    for item in path["items"]:  # these are the draw commands
        if item[0] == "l":  # line
            shape.draw_line(item[1], item[2])
        elif item[0] == "re":  # rectangle
            shape.draw_rect(item[1])
        elif item[0] == "qu":  # quad
            shape.draw_quad(item[1])
        elif item[0] == "c":  # curve
            shape.draw_bezier(item[1], item[2], item[3], item[4])
        else:
            raise ValueError("unhandled drawing", item)

• when finishing a path, do this:

    shape.finish(
        fill=path.get("fill", None),  # fill color
        color=path.get("color", None),  # line color
        dashes=path.get("dashes", "[] 0"),  # line dashing
        even_odd=path.get("even_odd", True),  # control color of overlaps
        closePath=path.get(
            "closePath", False
        ),  # whether to connect last and first point
        lineJoin=path.get("lineJoin", 0),  # how line joins should look like
        lineCap=max(path.get("lineCap", [0])),  # how line ends should look like
        width=path.get("width", 1),  # line width
        stroke_opacity=path.get("stroke_opacity", 1),
        fill_opacity=path.get("fill_opacity", 1),
    )

These changes are required, because this method contains tuples instead of Points or Rect.
Also there may now be quadrupels in the items list.
And there is now a distinction between "fill", "stroke" and combined paths.