Open wassfila opened 2 years ago
@wassfila Could we have more info about what you are using the SVG exports of the diagrams for?
@danyeaw thanks for the quick reply. The very common use case is creation of documentation report including all diagrams, this can take the form of a generated website with any sort of markdown or templating or other. One way or another, those multiple diagrams can end up on webpages or in a webapp, in which text search is of crucial usability importance, in addition to the possible auto markup augmentation, where for example known text uids, can be turned to url links automatically. here an example with website having svg shematics in searchable svg text https://www.homesmartmesh.com/docs/microcontrollers/nrf52/thread_sensortag/#schematics
Hi @wassfila, I hadn't noticed this. The SVG is rendered by Cairo and it's using Pango. I suppose that's why all glyphs are expressed as paths. The text API in cairo itself is considered a "toy api".
The advantage is that the image looks exactly as the diagram you see in Gaphor.
Downside is, as you describe, that there's no proper use of text tags in the SVG. I agree that it would be an advantage to have the text searchable.
Alternatively we need our own SVG renderer, which supports the Cairo API. But I'm not sure how to properly deal with fonts, in a system independent manner.
Any ideas?
Well, I can tell you that this is a matter of compromise, both fidelity and text tags would be hard, I can think, if from SVG standard it's possible and if so I'll update you. But all graphic designers for whom police is important, they never take risks of embedding fonts or risk breaking their SVGs. On the other hand, you're well into css support, so coding the characters as paths also loses the ability to customise the font with special css, which is also a down side. At the end of the day, you just need to make your target group happy, be it graphics designer or sw designers and some people will compain on either of choices you take. placing white or invisible text just for search might sound hacky, html image maps are for click effect only not for text search, and aria label also for focus help not for text search I think. A last resort of exposing this as export option might make the export process complex, but could be a simple way out, even if if it's kept as a developper only config option, many could profit from it.
What about exporting both way in the same svg?
That way the rendering will be ok and when searching the text will appear and position on the right place. That may increase svg size, but svgz exists and has a wide support.
Is this possible? or bad idea?
Hi, Thank you for considering this as a feature. Yes, that will definitely be an improvement compared to not being able to search the text at all. It is not pure svg that can be styled and enhanced, but pixel perfection is more important here, otherwise I admit allowing any change might violate the text positioning. Svg seems simple, but combining it in big pages induce unexpected complexities.
Is your feature request related to a problem?
I'm always frustrated when I get an SVG export from a tool that does not contain text info in text tags, like bitmaps or paths instead of text and span.That prevents text search in the page where svg is published. What is more important to search the export or to make it look nice with special police ? I'm leading SVG research and proof of concepts, see this example of deep linking augmentation, feel free to use it's MIT and if you have questions I'd be happy to help https://github.com/WebSVG/deep-svg
Describe the solution you'd like
Solution is to use text tags and spans instead of the current export that uses a reference "use" for each character
Describe alternatives you've considered
Such broken svg would require parsing other formats to get text, but still position is needed, so I'd have to convert to bitmap then back to svg with ocr tools just to get a text searchable diagram.
Additional context
It's such a great tool and promising, it would be such a pity not to think about the future of diagrams connectivity.