Add text functionality to schematic editor


From @dbrgn on Thu Nov 01 2018 19:43:34 GMT+0000 (UTC)

Right now text cannot be placed in the schematics. Would be nice to have that.

Desired functionality

  • Place text blocks on the schematics
  • Allow customizing font size and weight


  • Allow markdown formatting and only render on save (simplifies implementation)
  • Should font selection be per-block or for the entire sheet?
  • Format classes (heading1, heading2, text, small) would be nice to be able to achieve consistent formatting

    Copied from original issue:


From @ouabache on Fri Nov 02 2018 16:09:08 GMT+0000 (UTC)

Yes for Text.
Select font,size and color.
Do not place on snap grid,You need a finer adjustment for location.

If you do place on snap grid then allow for the 9 placement modifiers: above left,above,above right,left ,cent etc.

John Eaton


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 :slightly_smiling_face: 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…


Maybe we could translate Markdown to what’s supported by the Qt HTML renderer?


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.


Yes, I also think tables and hyperlinks would be quite useful.