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. Additional: 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.
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
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
Hi, 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, Nico.
[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. https://github.com/LibreCAD/libdxfrw/pull/51 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 https://github.com/LibreCAD/libdxfrw/commit/3519af1186871cc4bfd66ee670627816473a1ad8.patch relates to libdxfrw & /src/drw_entities.cpp. Is this the so-called Patch#51, or the replacement correction? https://github.com/LibreCAD/LibreCAD/issues/1545 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
(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!
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.
@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: 3519af1186871cc4bfd66ee670627816473a1ad8.patch 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: http://sophie.zarb.org/rpms/dd5cf6436df6031731093c3afdd84a55/files/5 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.
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. References: https://bugzilla.redhat.com/show_bug.cgi?id=2089001 https://github.com/LibreCAD/LibreCAD/issues/1543 https://github.com/LibreCAD/LibreCAD/issues/1545 ======================== Updated packages in core/updates_testing: ======================== dwg2dxf-1.1.0-0.rc1.1.mga8 lib(64)dxfrw1-1.1.0-0.rc1.1.mga8 lib(64)dxfrw-devel-1.1.0-0.rc1.1.mga8 librecad-2.2.0-0.rc4.1.mga8 librecad-data-2.2.0-0.rc4.1.mga8 librecad-doc-2.2.0-0.rc4.1.mga8 librecad-parts-2.2.0-0.rc4.1.mga8 librecad-plugins-2.2.0-0.rc4.1.mga8 from SRPMS: libdxfrw-1.1.0-0.rc1.1.mga8.src.rpm librecad-2.2.0-0.rc4.1.mga8.src.rpm
Status: NEW => ASSIGNEDAssignee: bugsquad => qa-bugsVersion: Cauldron => 8
CC: lewyssmith => (none)
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
(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
While at it, maybe we should be addressing the small issues mentioned in https://bugs.mageia.org/show_bug.cgi?id=29996#c27 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
@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: https://librecad.readthedocs.io/en/latest/appx/fonts.html 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?
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 compatibility). 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. :-)
Thank you John OKing this based on the comments above
CC: (none) => sysadmin-bugsKeywords: (none) => validated_updateWhiteboard: (none) => MGA8-64-OK
CC: (none) => davidwhodginsKeywords: (none) => advisory
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGAA-2022-0082.html
Status: ASSIGNED => RESOLVEDResolution: (none) => FIXED