Bug 112042 - idxf import filter not handling some text
Summary: idxf import filter not handling some text
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: filters and storage (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-08-26 18:02 UTC by V Stuart Foote
Modified: 2024-07-26 03:16 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
clip of attachment 109803 opened in Draw (15.83 KB, image/png)
2017-08-26 20:35 UTC, V Stuart Foote
Details
DXF opened in Irfanview, showing Text annotation (110.21 KB, image/png)
2017-08-26 22:36 UTC, V Stuart Foote
Details
clip of DXF opened with defaults in AutoDesk 2016 (65.97 KB, image/png)
2017-08-26 23:07 UTC, V Stuart Foote
Details
clip from DXF opened in CorelDraw 2017 (34.27 KB, image/png)
2017-08-26 23:54 UTC, V Stuart Foote
Details

Note You need to log in before you can comment on or make changes to this bug.
Description V Stuart Foote 2017-08-26 18:02:47 UTC
attachment 109803 [details] (SolidWorks showing ACADVER AC1015) from bug 86206 drops all its text with idxf import filter.

Looking at other bugs with DXF attachements, notice some of the more intricate DXF images are not very well handled by the idxf filter.
Comment 1 V Stuart Foote 2017-08-26 20:33:35 UTC
Some other DXF attachments in TDF BZ for any desired testing

attachment 53862 from bug 43082 (large drawing template with legend, all text well rendered).

attachment 79061 [details] from bug 64400 (truck chassis idxf filter chokes on it, just an bounding box is rendered in Draw, no text shows).

attachment 93153 [details] from bug 74299 (complex multi-axis graphs, Mike K had tweaked the text handling for these, but the bounding box is wrong on filter insert/open).

attachment 113990 [details] from bug 89901 (another truck chassis--this one is huge, idxf filter chokes on it and just a couple of line elements are rendered, even Irfanview chokes on it, but opens cleanly into CorelDraw 2017).

attachment 118567 [details] from bug 94067 (screw & plug adapter, text and other elements rendered pretty well in Draw insert/open, but suffers from dashed line export to SVG issue of bug 86206).

Tested on Windows 10 builds of 5.4.1.1 and 6.0.0a1+
Comment 2 V Stuart Foote 2017-08-26 20:35:26 UTC
Created attachment 135806 [details]
clip of attachment 109803 [details] opened in Draw
Comment 3 Jean-Baptiste Faure 2017-08-26 21:31:27 UTC
I get the same view in LO 5.4.0 (ubuntu) but that don't show if something is missing.
Please, could you attach a screencopy of what should be seen or describe a mean to check if something is missing in the view by Draw.

Best regards. JBF
Comment 4 V Stuart Foote 2017-08-26 22:36:19 UTC
Created attachment 135808 [details]
DXF opened in Irfanview, showing Text annotation
Comment 5 V Stuart Foote 2017-08-26 22:42:49 UTC
Just checked a Windows 3.3.0 build
LibreOffice 3.3.0 
OOO330m19 (Build:6)
tag libreoffice-3.3.0.4

Text was already missing at this point, so inherited from OOo.
Comment 6 V Stuart Foote 2017-08-26 23:07:02 UTC
Created attachment 135809 [details]
clip of DXF opened with defaults in AutoDesk 2016

Also, the LO rendering from 3.3.0 -> 6.0.0alpha1+ picks up most of the dimension lines as dashed, rather than solid as IrfanView (BabaCAD4Image plugin). 

Have to check again what CorelDraw 2017 seemed the labeling was more complete than with the AutoDesk 2016 clip.
Comment 7 V Stuart Foote 2017-08-26 23:54:48 UTC
Created attachment 135811 [details]
clip from DXF opened in CorelDraw 2017

in CorelDraw 2017 text annotation and mixed line types (dashed, solid) are present.
Comment 8 Mike Kaganski 2017-08-27 06:58:26 UTC
The dimensions in AutoCad drawings don't have their readings recorded in the file. Their readings are created at runtime based on the measurement, and formatted according to rules stored in dimension text (e.g., the text may simply override the measurement and output only static text, or pre-or postpone the measurement with static texts). The value measured may be taken in 3D, or in 2D based in current viewport. The problem is seen in IrfanView and CorelDraw, which ignore all customizations of the measurement formatting and try to calculate the values themselves.

I am not sure that what IrfanView (CorelDraw) do is any better than what Draw does.
Comment 9 Jean-Baptiste Faure 2017-08-27 07:32:48 UTC
(In reply to V Stuart Foote from comment #4)
> Created attachment 135808 [details]
> DXF opened in Irfanview, showing Text annotation

Thank you very much. :-)

Best regards. JBF
Comment 10 V Stuart Foote 2017-08-27 12:30:41 UTC
(In reply to Mike Kaganski from comment #8)
> The dimensions in AutoCad drawings don't have their readings recorded in the
> file. Their readings are created at runtime based on the measurement, and
> formatted according to rules stored in dimension text (e.g., the text may
> simply override the measurement and output only static text, or pre-or
> postpone the measurement with static texts). The value measured may be taken
> in 3D, or in 2D based in current viewport. The problem is seen in IrfanView
> and CorelDraw, which ignore all customizations of the measurement formatting
> and try to calculate the values themselves.
> 
> I am not sure that what IrfanView (CorelDraw) do is any better than what
> Draw does.

OK makes sense. And guess that means what shows as text in Draw must be present as static text in the DXF or it would not be rendered. Would expect annotation to be static, but most dimensioning in a CAD file would be intentionally dynamic and only have place holders. Which seems to be true with the drawing file from comment 0 opened into AutoDesk.

So, can we do better with the dimensioning/dynamic text or is it a lost cause that should just be noted in help for the filter?
Comment 11 Mike Kaganski 2017-08-27 17:00:07 UTC
(In reply to V Stuart Foote from comment #10)
> So, can we do better with the dimensioning/dynamic text or is it a lost
> cause that should just be noted in help for the filter?

Of course, we can do better. DXF has a good documentation, and there is reference implementation (closed-source) which may be consulted when some details need clarification wrt correct work. But given my past experience as AutoCAD user/programmer/teacher I can say that's rather big chunk of work. (Personally I don't have plans working on this.)
Comment 12 V Stuart Foote 2017-08-27 17:57:38 UTC
(In reply to Mike Kaganski from comment #11)
> Of course, we can do better. DXF has a good documentation, and there is
> reference implementation (closed-source) which may be consulted when some
> details need clarification wrt correct work. But given my past experience as
> AutoCAD user/programmer/teacher I can say that's rather big chunk of work.
> (Personally I don't have plans working on this.)

Fair enough :-)

Anyhow, I poked around in the LibreCAD project. Kind of wonder if their libdxfrw spinoff project might be worth investigating as a drop-in replacement for our idxf multipart import filter feed to dxf2mtf.

Supports both ASCII and binary DXF through ACAD 2015, could add support for DWG. And basis to write back out to DXF?

=-ref-=
https://sourceforge.net/p/libdxfrw/home/Home/
Comment 13 QA Administrators 2018-08-28 02:42:35 UTC Comment hidden (obsolete)
Comment 14 Xisco Faulí 2020-06-02 20:19:10 UTC
Still reproducible in

Version: 7.0.0.0.beta1+
Build ID: 2506d8221dd940dfd93d3d7c183430ba6ba3089d
CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded
Comment 15 QA Administrators 2022-06-03 03:35:32 UTC Comment hidden (obsolete)
Comment 16 V Stuart Foote 2022-07-26 19:51:55 UTC
(In reply to QA Administrators from comment #15)
idxf filter issue remains

Version: 7.5.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: 5df1bb4b1b222be00d25097660c4ee33542896ea
CPU threads: 8; OS: Windows 10.0 Build 19044; UI render: Skia/Vulkan; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL
Comment 17 QA Administrators 2024-07-26 03:16:21 UTC
Dear V Stuart Foote,

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
 
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not 
appropriate in this case)


If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword


Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug