Bug 30521 - https://github.com/LibreCAD/LibreCAD/issues/1545
Summary: https://github.com/LibreCAD/LibreCAD/issues/1545
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: 8
Hardware: All Linux
Priority: Normal major
Target Milestone: ---
Assignee: QA Team
QA Contact:
Whiteboard: MGA8-64-OK
Keywords: advisory, validated_update
Depends on:
Reported: 2022-06-07 19:30 CEST by Armin Stebich
Modified: 2022-06-13 22:45 CEST (History)
7 users (show)

See Also:
Source RPM: libdxfrw-1.0.1-1.1.mga8.src.rpm, librecad-2.2.0-0.rc3.1.mga8.src.rpm
Status comment:


Description Armin Stebich 2022-06-07 19:30:43 CEST
Description of problem:
Upstream, in LibreCAD, we got an issue reported about a malfunction with rotated text angles. See Summary link for details.

Steps to Reproduce:
1. Open LC-Bug-1545_Rotation-Issue_1ST-SAVE.dxf in LibreCAD, which is provided in the linked issue.
2. Save as ... the file with a new name, close and reopen it.
3. Close the renamed file.
2. Open the renamed file.
3. The rotated texts has different angles.

When I understand information for the package correct, it contains:
# Fix angle and alignment handling of (m)texts
# https://github.com/LibreCAD/libdxfrw/pull/51
Patch3:		https://github.com/LibreCAD/libdxfrw/commit/3519af1186871cc4bfd66ee670627816473a1ad8.patch

This pull request #51 is yet not merged in libdxfrw. The author also mentioned, that he is not sure about the correctness of this patch.

The issue reporter confirmed, that the latest AppImage 2.2.0-rc3-55-g12dc3ea1 does not have this issue.
So I applied this patch #51 to LibreCAD and was able to reproduce the issue with this build.

My conclusion is, that this patch #51 should not be contained in the libdxfrw package.
I haven't checked the other patches contained in the Mageia libdxfrw RPM yet. If you want me do do so, don't hesitate to get in touch.
Comment 1 John L. ten Wolde 2022-06-08 00:01:10 CEST
Hi Armin.  I'm "DeliveryFry", your upstream reporter.  Thank you so much for taking the time to analyze what had gone wrong and filing this report.

CC'ing: Dave Hodgins, David Walser, Lewis Smith, Morgan Leijström, Nicolas Salguero as you were all very much involved in the last round of LibreCAD/libdxfrw updates.  Also adding Jani Välimaa as he's listed as our libdxfrw maintainer.

Lewis and/or Morgan, did I get this right?  I hope I'm not overstepping.  Thanks everyone.

CC: (none) => davidwhodgins, davidwhodgins, fri, jani.valimaa, johnltw, lewyssmith, luigiwalser, nicolas.salguero

Comment 2 Armin Stebich 2022-06-08 08:18:27 CEST
No problem, you're welcome.

In case it helps, I have tagged and released LibreCAD 2.2.0-rc4 yesterday.
And also tagged libdxfrw 1.1.0-rc1, containing a new fix. 
The step in libdxfrw's minor version is because of new pure virtual methods, already contained in libdxfrw-1.0.1-1.1.mga8.src.rpm, which break compatibility with 1.0.1.

Updating LibreCAD is recommend too, because of https://bugzilla.redhat.com/show_bug.cgi?id=2089001, which was reported upstream for LibreCAD 2.2.0-rc3 too.

Thus I think using both above mentioned, tagged versions, should be save to use:
LibreCAD 2.2.0-rc4
libdxfrw 1.1.0-rc1
Comment 3 Nicolas Salguero 2022-06-08 14:25:46 CEST

LibreCAD 2.2.0-rc4 and libdxfrw 1.1.0-rc1 are now built for Cauldron and Mga8.

Do those versions fix the issue?

Best regards,

Comment 4 Lewis Smith 2022-06-08 15:00:52 CEST
[Clashed with prev comment]
    Thank you for this expert report (it seems that you are a LibreCAD developer), which is none-the-less confusing: which versions of LibreCAD itself, libdxfrw and patches matter.

    > I applied this patch #51 to LibreCAD and was able to reproduce the issue
    implies that the problem was not present before.

     fix angle and alignment handing of (m)texts #51 
    this clashes with 778d1d2:
    [ Fix bugs with .dwg import of TEXT and MTEXT entities
    Dwg files hold the alignment angles in radians, but dxf files need those in degrees. Multipliers were added to address this. Variable bool haveXAxis was renamed hasXAxisVec to better show use. Code added to set it properly. Changes to be committed: modified: drw_entities.cpp modified: drw_entities.h ]
    I cannot determine which is the correct fix

    relates to libdxfrw & /src/drw_entities.cpp. Is this the so-called Patch#51, or the replacement correction?

    is the upstream bug report, which says "They [Mageia] added unmerged LibreCAD/libdxfrw#51 pull request, which cause this issue"

    What we need to do you summarise:
    Comment 0
    "My conclusion is, that this patch #51 should not be contained in the libdxfrw package"
    Comment 2
    "I think using both ... tagged versions, should be safe to use:
    LibreCAD 2.2.0-rc4
    libdxfrw 1.1.0-rc1

    Thank you again for all your own work, and informing us.

CC: davidwhodgins, davidwhodgins, luigiwalser => (none)
Source RPM: libdxfrw-1.0.1-1.1.mga8.src.rpm => libdxfrw-1.0.1-1.1.mga8.src.rpm, librecad-2.2.0-0.rc3.1.mga8.src.rpm

Comment 5 Lewis Smith 2022-06-08 15:02:51 CEST
(In reply to Nicolas Salguero from comment #3)
> LibreCAD 2.2.0-rc4 and libdxfrw 1.1.0-rc1 are now built for Cauldron and
> Mga8.
PS to Nicolas: magic!
Comment 6 Armin Stebich 2022-06-08 20:44:25 CEST
Lewis, I hope I can shed light on the confusion.
Yes, I'm a LibreCAD maintainer, aka LordOfBikes.
The issue reported on GitHub was not reproducible with binaries built from GitHub code.
So to check the Mageia sources for LibreCAD/libdxfrw was obvious.
In the source list for libdxfrw I found patch #51, which is a pull request for libdxfrw. This pull request is neither tested nor merged in libdxfrw yet.
Also the changes from #51 are related with angles, what linked it to the described issue.

Because the issue was not reproducible with latest GitHub code, I applied the untested #51 to my local code base and could then reproduce the issue.

I was anyway preparing the mentioned release candidates. So both represent the latest stable code for LibreCAD and libdxfrw.
LibreCAD 2.2.0-rc4 will become the official release soon, when no more issues get reported.

I assume that the confusion with libdxfrw code arose because we haven't tagged versions for a while now. So your maintainer only tried to patch the code to a working level on his best knowledge and belief.
Now, with the tagged versions, there is no need to patch the code.

If anything else is vague, don't hesitate to get in touch.
Comment 7 John L. ten Wolde 2022-06-09 00:54:58 CEST
@Armin : Fantastic about the new RC4! Thanks again.

@Nicolas : Echoing what Lewis said, "magic!"  Geez, I can't keep up with any of you guys, and the fact that my timezone lags behind most of you by at least 8 hours sure doesn't help either.

Yes indeed, this new build resolves my upstream issue *and* hopefully others I haven't even gotten around to reporting about yet.  To me at least, this is tremendous!

@Lewis : In case you *are* finding what Armin's saying is vague, this might help.

When he's talking about "#51" he's calling the patch by its Pull request. He also listed it clearly by its full file name in Comment 0, and yes, it's the one you suspected:


If you navigate through our own App Database to Sophie's list of the contents of our source RPM for the malfunctioning (and now obsolete) libdxfrw 1.0.1, you will find it there under *exactly* that name.

Here's a direct link:


The upshot being that it *never* should have been included in our build at all.  How it got there when it shouldn't have?  Yeah, that's the question.

(In reply to Lewis Smith from comment #4)
>  confusing: which versions of LibreCAD itself, libdxfrw and patches matter?

Well, one thing Armin clearly hinted at to me in our conversation upstream is that libdxfrw goes hand-in-glove with LibreCAD.  Mixing them in any way out of sync with one another can easily result in "much wailing and gnashing of teeth".  Something I'd already started suspecting after that train wreck a few weeks back when I wrote Bug 29996 Comment 19. :-/

Thanks again to everyone for all their hard (and expedient) work.
Comment 8 Nicolas Salguero 2022-06-09 10:24:13 CEST
Suggested advisory:

The updated packages fix several bugs:

Application paths are empty by default, and translations are missing.

Various rotated entities shift from degrees to radians on file reload.


Updated packages in core/updates_testing:


from SRPMS:

Assignee: bugsquad => qa-bugs
Version: Cauldron => 8

Lewis Smith 2022-06-10 21:34:27 CEST

CC: lewyssmith => (none)

Comment 9 Herman Viaene 2022-06-11 11:38:59 CEST
MGA8-64 Plasma on Lenovo B50 in Dutch
No installation issues.
Opening Librecad lets me first choose my language, that works OK.
Then I can draw a few circles and rectangles OK on th layer 0
Then I wanted to add some text, I can define the text and its size, but all I get is the delineation of the text area.May text should be added in another layer. Tried to follow some YouTube video, but mostof it is beyond me.
If the higher powers judge this is enough of a test, I will not object the OK.

CC: (none) => herman.viaene

Comment 10 Armin Stebich 2022-06-11 12:46:01 CEST
(In reply to Herman Viaene from comment #9)
> Then I wanted to add some text, I can define the text and its size, but all
> I get is the delineation of the text area.

Off topic, not related to this bug.
See https://forum.librecad.org/only-empty-boxes-frames-are-shown-for-image-text-no-line-thickness-td5706737.html
Comment 11 Morgan Leijström 2022-06-12 11:31:35 CEST
While at it, maybe we should be addressing the small issues mentioned in

For the first part i see that when in drakrpm selecting - librecad-2.2.0-0.rc4.1.mga8.x86_64, lib64dxfrw1-1.1.0-0.rc1.1.mga8.x86_64 , so that seem OK.

But librecad-data-2.2.0-0.rc4.1.mga8.noarch seem to be still missing
wqy-unicode.lff from fonts subfolder
Comment 12 John L. ten Wolde 2022-06-12 12:39:32 CEST
@Morgan : Hi.  Yeah, sorry.  I *had* sort of addressed my own complaint in a followup report I'd filed at Bug 30379.  Dave saw it and closed it because, by my own admission, there was nothing more for us to do at that time -- at least as far as I could tell.  I was going to follow his advice so anyone still subscribed to Bug 29996 would get notified, but got busy with other things and completely forgot about it.

Anyway, to briefly reiterate:  based on the fonts listed in the current LibreCAD Manual, wqy-unicode.lff appears to have been *deliberately* taken out of circulation.  See here:


I haven't encountered an explicit explanation for its absence, but from my looking around upstream, I did see a handful of bugs (as yet unresolved) where users of CJK characters were experiencing less than satisfactory results with their text.

Perhaps Armin is willing to shed more light on this?
Comment 13 John L. ten Wolde 2022-06-12 23:57:11 CEST
To spare Armin from the extra hassle, I did some dedicated digging.

Eventually, I found my way to this bug report for Solvespace (I have no idea what that is), which happens to mention, and link, to the LibreCAD situation along the way.

Yes, the removal of wqy-unicode is intentional and was planned as far back as 2016 for the release of 2.2.0-rc1.  And the reason, as it turns out, was indeed its *enormous* 42MiB payload (and, apparently, dubious license

The Solvespace report:  https://github.com/solvespace/solvespace/issues/1042

The LibreCAD commit to remove it:  https://github.com/LibreCAD/LibreCAD/commit/382744d4ca1c151ce911cdf516c2b6d073b67b0e

I think that's got us sorted. :-)
Comment 14 Morgan Leijström 2022-06-13 08:06:00 CEST
Thank you John

OKing this based on the comments above

CC: (none) => sysadmin-bugs
Keywords: (none) => validated_update
Whiteboard: (none) => MGA8-64-OK

Dave Hodgins 2022-06-13 21:38:59 CEST

CC: (none) => davidwhodgins
Keywords: (none) => advisory

Comment 15 Mageia Robot 2022-06-13 22:45:27 CEST
An update for this issue has been pushed to the Mageia Updates repository.


Resolution: (none) => FIXED

Note You need to log in before you can comment on or make changes to this bug.