Better MText

[CivilGuy]

I've noticed that there are various features missing in the LibreCAD use of MText. The 'rich codes' that it recognizes are fairly limited.

In particular, I'd like to add in the features for setting a character width factor and underlining. I'd like MText able to set text into a list format. To do that, the app code should be able to automatically wrap text into a given box width.

Since no one else seemed to be working on it, I thought that I'd try my hand at it. The code will involve a rewrite of file rs_mtext.h and rs_mtext.cpp. I've got local draft code maybe 80% complete. It can be found at my fork of LibreCAD, https://github.com/CivilGuy/LibreCAD, branch CG_MText

I'd like to discuss what I've done with anyone who wants to hear about it. I've got a stream started on Zulip for the subject CodeBase/V2 MText.

Thanks.

[luiscar2001]

Dear CivilGuy,

I am particularly interested in this feature. I do not know if this is a problem of miscondiguration in my libercad but I am haviong problems with any interpretation of the MTEXT in dwg when opened from LibreCAD.,e.g. the text "{\pqc;\fArial|b0|i0|c0|p38;BATIMENT VOISIN N°99}" appears in the LibreCAD text box instead of importing as text just "BATIMENT VOISIN N°99" and using the rest of the tags for configuration. There is information on wht some codes are at
https://www.cadforum.cz/en/text-formatting-codes-in-mtext-objects-tip8640
but LibreCAD is not interpreting them.

Are you working on it? How can I help or contribute?

[CivilGuy]

It turned out to be more complex than I had thought and I put it aside to work on other interests. I've got things maybe 50% worked out. I have very little formal training in programming, and I admit that what I do have is very incomplete from a testing standpoint.
The current MTEXT dialog box needs work (more features), I think. My thought was to see if some better editor dialog box could be worked up as a temporary plug-in and propose that as a formal replacement if and when all the other bugs were worked out. And one thing leads to another so that modifications to various other classes would be needed, each of those to be made carefully.
A lot of this is only on my local clone, but since you're interested, I'll work on putting together something I can put into a branch on my Git Hub account, and let you see what I've accomplished. Still, it might take a week.

[luiscar2001]

This is indeed a feature that would improve a lot the way I can see the dwgs of my architect. Is there a way to make more relevant this feature?. I am looking forward to see your code and if I can contribute.
In order to maximize the value of the development, there are certain transformations that may be more relevant to me and also easy.
For example, see the code that appears in the mtext box when I click one of the texts in my architect's drawing:

{\pqr;\fArial|b0|i0|c0|p38;Revêtement mur pignon-mitoyen en ardoises gris\fArial|b0|i0|c0|p38; \fArial|b0|i0|c0|p38; ton foncé}

So, the code should realise that the mtext starts with "{" and decode it accordingly. There is no need to alter the text but just to interpret it accordingly when putting it in the drawing or in the Text box of the properties.

For the aforementioned code:

\pqr should change the lining and then not be shown in the text box (the same goes for pql and pqc

\fArial|b0|i0|c0|p38 should make the appropriate changes to the font. I realise that the text may have different fonts and styles in the same box and I do not know to what extend this is feasible in the current properties mtext box, which is the case of the mentioned line. However, a good start would be to consider only one style and format and format the whole box on that . The code will be improved the code from there on.
The first things to care of are b, i, c and p. We can then increase itnerpretaioon once fmore are required.

[CivilGuy]

Do you have any coding experience yourself? LibreCAD 2 is written in C++, and the changes I'd be making would use terminology from that, as well as from Git and QT, other components that LibreCAD is built around. I've put together a text file showing what I'm working on and what I hope to accomplish.
One thing you've noticed, of course, is that the various 'tags' used by AutoCAD are not very well documented. The codes b, i, c and p follow the \f tag and are font modifiers not supported by LibreCAD, so the thing to do would be to simply ignore them when displaying and printing the text. I nevertheless believe that they should be retained in the drawing's data.
There are other tags that I don't recognize at all, such as \pqc and \pqr. Those look like they're line justification codes - likely? Anyhow, I'd like to identify them, and probably incorporate them - later, probably.
1)Summary.txt

[lordofbikes]

Format Codes for Alternate Text Editor Reference

[luiscar2001]

I wouldn't say I have strong professional Coding experience as I have never made a living by with just coding. Although I studied ICT engineering my professional life has been rather at project management rather than implemenation. Anyway, I started coding more than 3 decades ago with my C64 both BASIC and ASM. Afterwards I passed to Pascal as it was part of a subject in university and later I had no escape from learning C as it was more ubiquotiuos. Of course I followed the derivatives, Delphi, Java but the internet era had arrvived and I moved to combining PHP and Javascript for my HTTP server. Lately I have learned Python because of its wide spread. Of course given my work I get more use from VBA. To tell you the truth I have never been fond of OOPs but I have no issue. Concerning C++, I have never coded on it (but Java) although I remember reading some book on it. I had enough with Delphi at the time and I was more productive with it. Anyway, if LibreCAD is in C++, no matter in adapting.

[luiscar2001]

I have looked in the code and it does seems feasible to do a correct interpretation of strings. From what I see, the fucntion to modify is
void RS_MText::update()
in src/lib/engine/rs_mtext.cpp
switch (data.text.at(i).unicode()) could start with case '{' as all the strings that are incorrectly represnted follow that for. This case should read all the characters following until the } or the end of the string and interpret every part accordingly. The parts seem separated by ";" and update() is already calling on functions to activate the different characteristics that the string contains (e.g. Font, bold, italics, superscript, subscript...)

[CivilGuy]

I think I've previously seen the page that lordofbikes provided (or an earlier version, maybe). It's a good reference, but it's incomplete. I've shown a more complete list in my notes above.
Most of the current code is in the functions update() and setText(). As I look at it, it seems to me that the better place to deal with the formatting tags is in setText(), not update().
An MText object is a multi-level tree sort of thing - at the bottom of the tree, the text is broken into individual characters which are used to look up the insert objects to actually draw. The incoming text needs to be split into the various substrings with their own particular formatting, and that formatting applied to laying out just where each character needs to go. This formatting is only changed when the incoming text string is changed, so that's why I think that setText() is where the bulk of the layout should happen.
The update() work takes place on the complete MText tree -- if that can be figured at the beginning, there's that much less work to be done every time update() needs to be called.
Or so I think, subject to correction.