From @ubruhin on Sat Nov 03 2018 22:31:51 GMT+0000 (UTC)
Support for text in schematics is needed for sure. But Iâm not sure about Markdown because itâs very limited and many EDA users probably donât know Markdown and thus arenât comfortable with it. But I would agree to use Markdown just as an optional, alternative input method for texts.
Qt would support a subset of HTML out of the box. With that it shouldnât be too hard to support rich text in LibrePCBâŚ
Choosing fonts is tricky. Actually only fonts bundled with LibrePCB should be used, the use of system fonts would break portability of LibrePCB projects.
From @dbrgn on Sun Nov 04 2018 11:27:00 GMT+0000 (UTC)
> With that it shouldnât be too hard to support rich text in LibrePCBâŚ
Sure, but if you want to do invisible markup (bold/italic/etc) by marking a span of text and clicking a format button, youâll descend into the seven hells of building rich text editors You probably know from using those how buggy they can be at times.
The advantage of markdown is that itâs visible how the markup should be applied, so you wonât have issues with incorrectly nested markup (or it will be obvious why it doesnât work).
One major advantage of markdown is thatâs its really simple and basically an industry standard. The problems with tying to the subset of html supported by Qt are numerous. The supported html is rather complex already and itâs possible to write rather complex webpages with it (it supports a subset CSS and so on). If users can abuse something, they will. Additionally, tying to Qt would mean we donât have control over the functionality. Imagine if further down the road Qt started supporting more tags or less. Then users using newer version of Qt would observe different behavior of librepcb compared to users using old version of Qt. I guess we want to avoid that.
Yes, I absolutely agree. But the problem is when not using Qtâs HTML renderer, we would have to implement it by ourselves, which requires very high effort. Using Qt for that would be much simpler. Maybe we could somehow restrict the supported HTML subset by ourselves, so that we can control which HTML tags are allowed and which not? That would be at least a good compromise in my opinionâŚ
I think that could be a reasonable way to implement Markdown support.
If weâd pick Markdown though, weâd have to limit the supported features, since Markdown generally allows arbitrary HTML. I think bold/italic/strikethrough and different levels of headlines would be sufficient. (We probably donât want to support things like inline-images and hyperlinks, right?)
Iâd actually be in favor of hyperlink support, if it doesnât cost anything to add. It might not be useful enough to bother adding, but itâs useful enough not to go out of your way to block.
Someone could use it to link to a license document, or the homepage of a product, etc. It Might not be âtraditional schematic styleâ, but some may find it useful, and itâs no more of a security issue than any other hyperlink.
Some people might not like it if images could be loaded externally, they might think itâs a privacy problem, so images probably wouldnât work.
Tables, however, could actually be useful for showing alternatively part values in different configurations.
As alternate pin function doesnât exist for now, the schematic annotation functionality would be helpful.
And after implementation of alternate pin, it will remains helpful for initial issue authorâs reasons !
Iâd like to implement this feature soon. But to be honest, after thinking about this again, it feels like a nightmare to support any kind of formatting. Markup languages like HTML (converted from Markdown or not, doesnât matter) are horrible to render in a graphics view, export to PDF etc. in a framework independent way. It might be easy to support this at the moment with Qt and QGraphicsView. But what if we ever want to switch to a different rendering engine? IMHO itâs almost impossible to get the same rendering result with a different engine.
In addition, supporting hyperlinks could be quite complicated since then parts of a text item (not the whole text!) need to be clickable. If not supported out of the box by the rendering engine, this would be almost impossible to implement properly.
It seems that most of the other EDA tools do not support rich text as well. KiCad even doesnât support TrueType fonts, you can only add very simple stroke texts to the schematic. Eagle (checked in v7.5.0) supports TrueType fonts, but no markup features at all (no italic, no bold, âŚ). Altium seems to support configuring the the font, italic, bold etc. but only for the whole text.
In the end, I think the best way would be to copy the simple text labels from the symbol editor to the schematic editor, i.e. providing exactly the same functionality as in the symbol editor (no markup at all). If really needed, probably we could still add some more functionality to that text labels some day (italic, bold, color, âŚ).
And if we ever want to support tables (I think sometimes they are useful indeed), Iâd propose to add a new object type called âtableâ which simply consists of lines and text labels.
You probably know from using those how buggy they can be at times.