How can i get text property "fill" from pdf

[little-polka-dot]

Is your feature request related to a problem? Please describe.

I found some red characters with color property (0, 0, 0).
Do these characters have any additional attributes, such as “fill”?
thanks!

Describe the solution you'd like

Describe alternatives you've considered

Additional context

[JorjMcKie]

A typical "Discussions" post. Let me transfer first.

[JorjMcKie]

Hard to tell based on this little information. Please provide the example file.

[JorjMcKie]

Some information upfront:
For text extractions with options "dict"/"rawdict" the reported color (always given in sRGB format) is the fill color. This also is the standard / default for text in PDF (text render mode 0 = 0 Tr).
However, text written with render mode 1 is "stroked", meaning only the character borders are visible.
Render mode 2 means stroke + fill. All this looks like so (Adobe manual):

To get access to the stroke color, you must invest in some coding unfortunately:

There is a low-level way to extract text: page.get_texttrace(). This is somewhat similar to the "rawdict" option in terms of detail.
It delivers dictionaries of text characters having the same properties. Text written with stroke and fill character appear as two separate, consecutive dictionaries: one for the fill color and another one for the stroke color. The dictionaries are identical - except for their types, which are 0 for "fill" and 1 for "stroke".
The "color" dictionary key in each dictionary therefore has to be interpreted as fill or stroke color respectively.

So much for that.

To find the stroke color of a text span contained in get_text("dict"), you would have to do the following:

1. Set fitz.TOOLS.set_small_glyph_heights(True). This will ensure minimal text bbox heights.
2. Extract text via page.get_text("dict") and locate a text span within the output.
3. Take the span bbox and see if it is contained in one of the bboxes of page.get_texttrace() dictionaries that has "type" equal to 1.
4. If found, the "color" value of that dictionary is the stroke color of your text span.

[little-polka-dot]

上海石化2021年年度报告.pdf

Thank you for your answer.
In this Pdf No.145, i found some hidden characters with color (0, 0, 0).
There are no drawings and no images in this page and there is no situation where these characters are covered.
Why these characters are invisible?

[JorjMcKie]

Invisibility may happen for a number of reasons:

• text covered by something else (image, vector graphics)
• text has same color as background (like black on black)
• text is under control of rendering mode 3 = 3 Tr. This is very often used by OCR: recognized text is written to the page with this rendering mode - at the same spot where the text in the image was found, thus making it selectable / searchable.

The motivation for invisible text in your case? Hard to tell. Maybe someone wanted to store an explanation that the normal user shouldn't see ... who knows.

[little-polka-dot]

And i have another confusion，does this method "page.get_texttrace" always return font-size 0 when the character is rotated 90 or -90 degrees?

[JorjMcKie]

And i have another confusion，does this method "page.get_texttrace" always return font-size 0 when the character is rotated 90 or -90 degrees?

No, it should return the correct font size. However, fonts may contain errors. And the code behind get_texttrace() may also have an error 😉.
Please do not hesitate to submit a bug if you believe there is a problem.

[little-polka-dot]

okay...thanks

[little-polka-dot]

https://pymupdf.readthedocs.io/en/latest/functions.html#Page.get_texttrace
I found pymupdf documentation describes this, "the font flags value will never contain a superscript flag bit"
But superscript flag is at position 2^0 and i found flags returned by get_texttrace() is same as that returned by get_text().
Is there a documentation that provides a detailed introduction to it?

[JorjMcKie]

Best look here and scroll down to "Span Dictionary". The font flag bits are computed from corresponding font properties. The "superscript" bit is computed using the text position and bbox size in relation to subsequent text - not from the font.

[little-polka-dot]

Yes, you are right. But what I'm confused about is actually another flags, that returned by get_texttrace()

[little-polka-dot]

Is there a documentation about this?

[JorjMcKie]

No. I compute the flags in that method from font properties in the same way. But because the approach is so much different than that of TextPage (all the heuristics of MuPDF are missing), I do not bother to identify superscripts.
As a general comment:

• These flags are what the font tells us about itself. It need not be true, and there is no way to determine this.
• Text may appear bold but may be faked so with a normal font.

[little-polka-dot]

Thanks