# Underlines not handled by pymupdf4llm.to\_markdown **URL:** \ **Category:** PyMuPDF\ **Created:** [July 22, 2025, 1:16pm UTC](https://forum.mupdf.com/t/underlines-not-handled-by-pymupdf4llm-to-markdown/73 "2025-07-22T13:16:51Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![Steen\_Larsen](https://yyz2.discourse-cdn.com/flex004/user_avatar/forum.mupdf.com/steen_larsen/32/99_2.png) [@Steen\_Larsen](https://forum.mupdf.com/u/Steen_Larsen)\ **Post date:** [July 22, 2025, 1:16pm UTC](https://forum.mupdf.com/t/underlines-not-handled-by-pymupdf4llm-to-markdown/73/1 "2025-07-22T13:16:52Z")
I am using pymupdf4llm.to\_markdown to extract patient leaflet information inside PDF documents from the European Medicines Agency. The PDF I am using has underlined text which does not appear underlined in the outputted md file. On one occurrence the md file contains 9 tabs followed by the text that should have been underlined and in other circumstances I simply get the text without any formatting at all. I would have expected underlined text using the the \\ markup Snippet from page 2 in the PDF looks like this: ![image](https://canada1.discourse-cdn.com/flex004/uploads/mupdf/original/1X/ac8860902af3a64c285120a419f6a4d80aac7477.png) The markup output is this: ```auto **2.** **QUALITATIVE AND QUANTITATIVE COMPOSITION** 1 mL of the solution contains 100 units of insulin aspart* (equivalent to 3.5 mg). Fiasp 100 units/mL FlexTouch solution for injection in pre filled pen Each pre-filled pen contains 300 units of insulin aspart in 3 mL solution. Fiasp 100 units/mL Penfill solution for injection in cartridge ``` Is this a bug or a feature? 🙂 The file is : [https://www.ema.europa.eu/en/documents/product-information/fiasp-epar-product-information\_en.pdf](https://www.ema.europa.eu/en/documents/product-information/fiasp-epar-product-information_en.pdf) I use the demo code below. import pymupdf4llm md\_text = pymupdf4llm.to\_markdown(“/pleaflet/samples/fiasp-epar-product-information\_en.pdf”, write\_images=True, force\_text=False, image\_size\_limit=0)) import pathlib pathlib.Path(“noutput.md”).write\_bytes(md\_text.encode()) ---
**Author:** ![system](https://canada1.discourse-cdn.com/flex004/uploads/mupdf/original/1X/59de15e5b1831c7397f2bb7ac73628b1f408d0c2.png) [@system](https://forum.mupdf.com/u/system)\ **Post date:** [July 22, 2025, 1:53pm UTC](https://forum.mupdf.com/t/underlines-not-handled-by-pymupdf4llm-to-markdown/73/2 "2025-07-22T13:53:01Z")
Unlisted on July 22, 2025, 1:53pm UTC ---
**Author:** ![system](https://canada1.discourse-cdn.com/flex004/uploads/mupdf/original/1X/59de15e5b1831c7397f2bb7ac73628b1f408d0c2.png) [@system](https://forum.mupdf.com/u/system)\ **Post date:** [July 22, 2025, 2:09pm UTC](https://forum.mupdf.com/t/underlines-not-handled-by-pymupdf4llm-to-markdown/73/3 "2025-07-22T14:09:42Z")
Listed on July 22, 2025, 2:09pm UTC ---
**Author:** ![Jamie\_Lemon](https://yyz2.discourse-cdn.com/flex004/user_avatar/forum.mupdf.com/jamie_lemon/32/5_2.png) [@Jamie\_Lemon](https://forum.mupdf.com/u/Jamie_Lemon)\ **Post date:** [July 22, 2025, 3:01pm UTC](https://forum.mupdf.com/t/underlines-not-handled-by-pymupdf4llm-to-markdown/73/4 "2025-07-22T15:01:40Z")
Not sure in the results which it italicised the _Fiasp 100 units/mL FlexTouch …_ , so I would say that is a bug. There is no native underline tag in Markdown though, so we would need to consider extending the method to insert HTML like syntax such as `` if we were to support this feature. ---
**Author:** ![HaraldLieder](https://yyz2.discourse-cdn.com/flex004/user_avatar/forum.mupdf.com/haraldlieder/32/14_2.png) [@HaraldLieder](https://forum.mupdf.com/u/HaraldLieder)\ **Post date:** [July 22, 2025, 3:07pm UTC](https://forum.mupdf.com/t/underlines-not-handled-by-pymupdf4llm-to-markdown/73/5 "2025-07-22T15:07:57Z")
There exists no way to render underlines in Markdown! ---
**Author:** ![Steen\_Larsen](https://yyz2.discourse-cdn.com/flex004/user_avatar/forum.mupdf.com/steen_larsen/32/99_2.png) [@Steen\_Larsen](https://forum.mupdf.com/u/Steen_Larsen)\ **Post date:** [July 23, 2025, 11:55am UTC](https://forum.mupdf.com/t/underlines-not-handled-by-pymupdf4llm-to-markdown/73/6 "2025-07-23T11:55:46Z")
Yes and no. My understanding is that markdown has a murky past where certain perl scripts were the spec. and that some topics are sort of greyzones and undefined even today. Regarding underline: 1. Github specifies \ for underline here : [Basic writing and formatting syntax - GitHub Docs](https://docs.github.com/en/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax) - I also tested it in a README.md file where it displayes with underline on github. 2. This platform handles \ as this 3. Interestingly this spec does not mention any support for underline. [GitHub Flavored Markdown Spec](https://github.github.com/gfm/#emphasis-and-strong-emphasis) 4. My visual studio code markdown previewer supports \ and shows it as underlined The HTML tag \ does not work on github and this platform. It only works in my VSC markup previewer. IMHO it would make sense to support the \ tag for underline in markup. PS. Sadly \_text\_ gives _italic_ in markup because the original author preferred to reserve underline for links. This made sense when markup was used for web only. But today it is used for many non-web purposes. ---
**Author:** ![HaraldLieder](https://yyz2.discourse-cdn.com/flex004/user_avatar/forum.mupdf.com/haraldlieder/32/14_2.png) [@HaraldLieder](https://forum.mupdf.com/u/HaraldLieder)\ **Post date:** [July 23, 2025, 1:38pm UTC](https://forum.mupdf.com/t/underlines-not-handled-by-pymupdf4llm-to-markdown/73/7 "2025-07-23T13:38:59Z")
Well, of course we _ **could** _ support the ``. But I don’t want to do that. Reasons: - Support among renderers is limited because not part of the official syntax. LLMs may not / will not understand what they are getting. - Text volume may be bloated considerably by the long strings `` / ``. - The purpose is purely esthetical. It plays no role in LLM workflows. If at all we might consider outputting it as “bold”. - There is a fundamental uncertainty WRT to detection: Text “accidentally” above horizontal lines cannot be told apart from being truly underlined. Examples: - page separator lines (e.g. page headers separated from page body) - text in tables having grid lines: would cause all cell text to be underlined. ---
**Author:** ![Steen\_Larsen](https://yyz2.discourse-cdn.com/flex004/user_avatar/forum.mupdf.com/steen_larsen/32/99_2.png) [@Steen\_Larsen](https://forum.mupdf.com/u/Steen_Larsen)\ **Post date:** [July 29, 2025, 9:27am UTC](https://forum.mupdf.com/t/underlines-not-handled-by-pymupdf4llm-to-markdown/73/8 "2025-07-29T09:27:04Z")
Thanks for your answer! I really appreciate you taking time for this. Even if I don’t agree fully. > [@HaraldLieder](#): > > Support among renderers is limited because not part of the official syntax. LLMs may not / will not understand what they are getting. As I wrote above it seems most renderers support \. All 3 I use did. Should somebody not support it they will simply ignore the tag and no harm will be done. > [@HaraldLieder](#): > > Text volume may be bloated considerably by the long strings `` / ``. I really don’t see that as an issue. If you really think that is an issue why don’t you see a problem supporting **bold** text? The difference between \*\* for bold and the \ tag for an underline is only 7 bytes. Not an issue in any LLM context IMHO. (Unless some idiot tries to individually underline every character in a document 😀 ) > [@HaraldLieder](#): > > The purpose is purely esthetical. It plays no role in LLM workflows. If at all we might consider outputting it as “bold”. My use case is using LLMs to edit documents. Extracting relevant text and reformatting it. Something which replaces a lot of cumbersome manual work. For this use case the formatting is very important. I am sure other people do this too. If you don’t think aesthetics count then why are we bothering with formatting at all? > [@HaraldLieder](#): > > There is a fundamental uncertainty WRT to detection: Text “accidentally” above horizontal lines cannot be told apart from being truly underlined. Examples: > > - page separator lines (e.g. page headers separated from page body) > - text in tables having grid lines: would cause all cell text to be underlined. That is a good point. As a first simple step you could support the simple case where the PDF font itself is underlined. That should be pretty simple and cover 90% of use cases. Talking about text and nearby lines I actually saw a problem in your table handling where text inside the table was detected as ~~strike through~~ I will look for this and describe it in a separate post. ---
**Author:** ![Jamie\_Lemon](https://yyz2.discourse-cdn.com/flex004/user_avatar/forum.mupdf.com/jamie_lemon/32/5_2.png) [@Jamie\_Lemon](https://forum.mupdf.com/u/Jamie_Lemon)\ **Post date:** [July 29, 2025, 12:33pm UTC](https://forum.mupdf.com/t/underlines-not-handled-by-pymupdf4llm-to-markdown/73/9 "2025-07-29T12:33:40Z")
I could see an argument for an extra parameter in `to_markdown` which could be “support unofficial MD syntax”, `support_extended_md` maybe? If this was set to True ( False by default) then it could try and parse the document with regards to looking for underlines and providing `` insertions. But I don’t think this should be default behaviour. Regarding the detection issue - I think we would likely get quite a few false positives if text is super close to line drawn tables. Additionally as I understand it , there is no such thing as “an underlined font” - so the idea of a PDF font which is underlined doesn’t make sense to me here! ---
**Author:** ![HaraldLieder](https://yyz2.discourse-cdn.com/flex004/user_avatar/forum.mupdf.com/haraldlieder/32/14_2.png) [@HaraldLieder](https://forum.mupdf.com/u/HaraldLieder)\ **Post date:** [August 13, 2025, 3:36pm UTC](https://forum.mupdf.com/t/underlines-not-handled-by-pymupdf4llm-to-markdown/73/10 "2025-08-13T15:36:11Z")
@Steen_Larsen Sorry, but I have to confront you with reality: Underline, strikeout (and fake-bold) **_are no font properties_**! Your _“should cover 90% of the use cases”_ therefore is something that would be called a _hallucination_ if you were an AI 😉. There exists no font in this world with any of these properties! Underline and strikeout detections **_always_** are the result of matching text boundary boxes with the y-locations of horizontal lines - either originating from vector graphics or from appropriate annotations. So my argument remains undefeated: We cannot (and therefore will not try to) support underline styling in markdown output for the foreseeable time because of at least two reasons: - missing Markdown syntax support - impossibility to disambiguate general horizontal lines and intentional text underlining The second argument is the more important one, admittedly. We have no desire to be flooded with issues claiming that we incorrectly styled normal text as being underlined.