Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Control texmode via SVG attribute #194

Merged
merged 9 commits into from
May 10, 2024

Conversation

fberlakovich
Copy link

Description

The PR fixes an issue with output to stdout and adds the ability to select the texmode with an SVG attribute.

Use Case

I use svg2tikz to convert SVGs exported from draw.io to tikz. Most of the time I want to use the convenient text formatting options in draw.io. Sometimes, however, I want to use some latex feature in e.g. a label of an object, but keep the text formatting of all other objects. With this PR, I can add a custom attribute to the label that specifies its text should be interpreted raw. The text of the label then containts the necessary Latex code, whereas all other labels retain their draw.io formatting.

Type of change

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)

How Has This Been Tested?

The PR includes a file test for the new feature.

@ldevillez
Copy link
Collaborator

ldevillez commented May 3, 2024

Hello @fberlakovich, Thanks for the PR :)
Could you implement those fixes:

  • Add your FIX and your ADD to the changelog
  • Define your find_attribute inside the class directly and not in the _handle_text function. You can change it to a private class method (maybe change the name to something like _find_attribute_text)
  • Do you think this could be useful to people using Inkscape ? (and then updating the .inx to update the .inx extension).
  • Add in your svg file other instance of data-texmode for the others mode of text-rendering ?

@fberlakovich
Copy link
Author

fberlakovich commented May 3, 2024

Hello @fberlakovich, Thanks for the PR :) Could you implement those fixes:

  • Add your FIX and your ADD to the changelog
  • Define your find_attribute inside the class directly and not in the _handle_text function. You can change it to a private class method (maybe change the name to something like _find_attribute_text)
  • Do you think this could be useful to people using Inkscape ? (and then updating the .inx to update the .inx extension).
  • Add in your svg file other instance of data-texmode for the others mode of text-rendering ?

Sure, no problem. Regarding Inkscape: maybe. I have zero experience with Inkscape and don't know if Inkscape allows adding/editing custom SVG properties. I can have a look though.

@ldevillez
Copy link
Collaborator

For Inkscape, modifying the .inx is not complicated but if you do not have Inkscape, you can just create an issue for that part and I will do it myself later

@fberlakovich
Copy link
Author

For Inkscape, modifying the .inx is not complicated but if you do not have Inkscape, you can just create an issue for that part and I will do it myself later

Could you have another look? I added the requested changes (I think).

Btw, my endgoal would be to use this new feature to selectively export text to either math text, raw text, escaped text or text converted to paths. Certain formatting options in draw.io are hard to translate to latex text formatting (font name alone is difficult, because latex uses the berry naming scheme for font names...), but I haven't found an angle yet to selectively achieve the text to path conversion.

@ldevillez ldevillez mentioned this pull request May 5, 2024
9 tasks
@ldevillez
Copy link
Collaborator

Hello @fberlakovich
Thanks Again :)

There is also tikz_export_output.inx to update (the changes will be also the sames as tikz_export_effect.inx). The purpose of this file is to create an extension when exporting file ;)

Also don't forget to use black (for the formating) (the tests are failing).

Text formating is complicated with Latex that's also why this feature is not so well developed in the code base. For example scaling a svg will impact font size, but this is not taken into account in the tikz code for now.

@fberlakovich
Copy link
Author

There is also tikz_export_output.inx to update (the changes will be also the sames as tikz_export_effect.inx). The purpose of this file is to create an extension when exporting file ;)

Also don't forget to use black (for the formating) (the tests are failing).

Thanks for pointing it out, fixed.

Text formating is complicated with Latex that's also why this feature is not so well developed in the code base. For example scaling a svg will impact font size, but this is not taken into account in the tikz code for now.

I have a prototype that parses the HTML in the foreignObject draw.io creates for a formatted text object, sends it through wkhtmltopdf to obtain a PDF and then uses inkscape to obtain the PDF as SVG. It should be possible to convert the resulting SVG to tikz and, thus, have the formatted text as tikz paths (although not as proper text). I think it is relatively specific to my usecase (mix text formatted in draw.io and latex code), but if you are interested I can share the code / create a PR. The fact that many tools (not just draw.io, also, e.g., mermaidjs) create HTML foreignObjects to style text in SVG is an ongoing issue I am afraid.

@fberlakovich
Copy link
Author

I am really sorry, I forgot formatting the tests 🤦 . I will fix it right away and also try to run the workflow locally to avoid future mistakes

@fberlakovich
Copy link
Author

I fixed the formatting issue and also, what I believe, is a typo in the pylint action.

@ldevillez
Copy link
Collaborator

There is also tikz_export_output.inx to update (the changes will be also the sames as tikz_export_effect.inx). The purpose of this file is to create an extension when exporting file ;)
Also don't forget to use black (for the formating) (the tests are failing).

Thanks for pointing it out, fixed.

Text formating is complicated with Latex that's also why this feature is not so well developed in the code base. For example scaling a svg will impact font size, but this is not taken into account in the tikz code for now.

I have a prototype that parses the HTML in the foreignObject draw.io creates for a formatted text object, sends it through wkhtmltopdf to obtain a PDF and then uses inkscape to obtain the PDF as SVG. It should be possible to convert the resulting SVG to tikz and, thus, have the formatted text as tikz paths (although not as proper text). I think it is relatively specific to my usecase (mix text formatted in draw.io and latex code), but if you are interested I can share the code / create a PR. The fact that many tools (not just draw.io, also, e.g., mermaidjs) create HTML foreignObjects to style text in SVG is an ongoing issue I am afraid.

Can we not directly convert ForeignObject to path with inkscape (and thus inkex) ? But feel free to share the code open an issue to discuss it. We need to see if it integrate wells with the base code of svg2tikz :)

But thanks again for PR :)

@ldevillez ldevillez merged commit a0d38db into xyz2tex:master May 10, 2024
4 checks passed
@fberlakovich
Copy link
Author

Can we not directly convert ForeignObject to path with inkscape (and thus inkex) ? But feel free to share the code open an issue to discuss it. We need to see if it integrate wells with the base code of svg2tikz :)

The reason why Inkscape (to the best of my knowledge) can't deal with ForeignObjects is that they can contain almost anything. In the case of draw.io and a few other tools, they contain a HTML+CSS representation of the object. Thus, Inkscape would need a full fledged browser engine to interpret the contents. This fact also makes it difficult to simply "parse" the contents.

wkhtmltopdf handles the heavy lifting of rendering the HTML with Webkit (thus, wk in the name), but can only convert to PDF, not directly to SVG. Inkscape on the other hand, can convert from PDF to SVG, leading to the chain ForeignObject (HTML+CSS) -> wkhtmltopdf (PDF) -> inkscape (SVG).

I didn't get round to working on the conversion since I posted my comment, but will share the code as soon as it is functional.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants