Bug 168265 - FILEOPEN: DXF files with comments lines are no longer recognized as drawings and are therefore not opened by Draw but by Writer as text files
Summary: FILEOPEN: DXF files with comments lines are no longer recognized as drawings ...
Status: ASSIGNED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Draw (show other bugs)
Version:
(earliest affected)
7.5 all versions
Hardware: x86-64 (AMD64) All
: medium normal
Assignee: Julien Nabet
URL:
Whiteboard: target:26.2.0
Keywords: bibisected, bisected, possibleRegression
Depends on:
Blocks:
 
Reported: 2025-09-03 10:27 UTC by Gianni
Modified: 2025-09-06 09:46 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Sample DXF file without top comments (24.57 KB, text/plain)
2025-09-03 10:29 UTC, Gianni
Details
Sample DXF file with top comments (24.64 KB, text/plain)
2025-09-03 10:29 UTC, Gianni
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Gianni 2025-09-03 10:27:22 UTC
Description:
DXF files with comments lines exhibit the bug.

In a DXF file, comments are specifically defined lines of text preceded by the group code 999.
This code signifies that the subsequent line of text is a comment and should be ignored by DXF-aware software.

Reference:

Autodesk AutoCAD 2024 / DXF Group Codes in Numerical Order Reference
https://help.autodesk.com/view/OARX/2024/ENU/?guid=GUID-3F0380A5-1C15-464D-BC66-2C5F094BCFB9

Comments examples:

These lines are inserted on top of the DXF file by Potrace https://potrace.sourceforge.net/
999
DXF data, created by potrace 1.16, written by Peter Selinger 2001-2019

These lines are inserted on top of the DXF file by Inkscape when Saving as Desktop Cutting Plotter (AutoCAD DXF R12) (*.dxf)
999
“DXF R12 Output” (www.mydxf.blogspot.com)

Anyway, if I Drag and Drop those files on a Draw blank page, they are recognized as drawings.

Note:

I must add that if the comments are not on top of the DXF file, LibreOffice don't like it at all an throw various errors:

Filtro immagine non trovato
[OK]

Errore generale.
Errore generale di I/O.
[OK]

but this is a case that in real life I have never encountered.

Testing:

To help doing some testing, I have attached two DXF sample files, one with comments and one without.


Steps to Reproduce:
1.Open a DXF file containing comment lines
2.
3.

Actual Results:
The file opens in Writer as a text file

Expected Results:
The file should opens in Draw as a drawing


Reproducible: Always


User Profile Reset: No

Additional Info:
Version: 7.5.0.1 (X86_64) / LibreOffice Community
Build ID: 77cd3d7ad4445740a0c6cf977992dafd8ebad8df
CPU threads: 2; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win
Locale: it-IT (it_IT); UI: it-IT
Calc: CL threaded

I have tested many but not all LibreOffice versions.

These versions don't exhibit the bug:
5.3.3.2
6.3.5.2
7.1.7.2
7.2.7.2
7.3.7.2
7.4.7.2

These versions exhibit the bug:
7.5.0.1
7.5.7.1
7.5.9.2
7.6.7.2
24.2.5.2
24.8.7.2
25.2.4.3
25.2.5
25.2.5.2
25.8.1.1
Comment 1 Gianni 2025-09-03 10:29:00 UTC
Created attachment 202673 [details]
Sample DXF file without top comments
Comment 2 Gianni 2025-09-03 10:29:35 UTC
Created attachment 202674 [details]
Sample DXF file with top comments
Comment 3 Julien Nabet 2025-09-04 12:53:58 UTC
On pc Debian x86-64 with master sources updated today.
Remark: the one without comments doesn't open on Writer but fails with general error on Draw.

Xisco: trying to find the root cause, I noticed that the one without comments goes there:
Thread 1 "soffice.bin" hit Breakpoint 2, SfxBaseModel::load (this=0x55a869297a30, seqArguments=uno::Sequence of length 16 = {...}) at sfx2/source/doc/sfxbasemodel.cxx:1967
1967	    if( m_pData->m_pObjectShell->GetMedium() )
(gdb) p seqArguments
$10 = uno::Sequence of length 16 = {{Name = "DocumentService", Handle = 0, Value = uno::Any("string": "com.sun.star.drawing.DrawingDocument"), 


the other one with comments goes:
#0  SfxBaseModel::load (this=0x55a8687f1cb0, seqArguments=uno::Sequence of length 16 = {...}) at sfx2/source/doc/sfxbasemodel.cxx:1967
1967	    if( m_pData->m_pObjectShell->GetMedium() )
(gdb) p seqArguments
$9 = uno::Sequence of length 16 = {{Name = "DocumentService", Handle = 0, Value = uno::Any("string": "com.sun.star.text.TextDocument"), 

but don't find the precise location where file detection is done.
Comment 4 Saburo 2025-09-06 06:33:18 UTC
reproducible
Version: 26.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: d3f499361039b7933dfdae405dabdc8b631dcf79
CPU threads: 4; OS: Linux 6.14; UI render: default; VCL: gtk3
Locale: ja-JP (ja_JP.UTF-8); UI: en-US
Calc: threaded

bibisected with linux-64-7.5
commit 45705461d4597b736c44e006360f9072eed3fe85	[log]
author	offtkp <parisoplop@gmail.com>	Sun Aug 07 22:24:39 2022 +0300
committer	Tomaž Vajngerl <quikee@gmail.com>	Fri Aug 19 10:23:47 2022 +0200

Remove code duplication in GraphicDescriptor for DXF

GraphicFormatDetector and GraphicDescriptor have duplicate format
detection code so now GraphicDescriptor uses GraphicFormatDetector
functions instead to detect the format for DXF files

Change-Id: I13a3c40ee35259b6b61aa323f4fa5af73290e94b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137935
---
adding CC: parisoplop
Comment 5 Julien Nabet 2025-09-06 07:31:48 UTC
(In reply to Saburo from comment #4)

> bibisected with linux-64-7.5
> commit 45705461d4597b736c44e006360f9072eed3fe85	[log]
> author	offtkp <parisoplop@gmail.com>	Sun Aug 07 22:24:39 2022 +0300
> committer	Tomaž Vajngerl <quikee@gmail.com>	Fri Aug 19 10:23:47 2022 +0200
> 
> Remove code duplication in GraphicDescriptor for DXF
> 
Thank you for the bibisect!
I've submitted a patch on gerrit here:
https://gerrit.libreoffice.org/c/core/+/190632
Comment 6 Commit Notification 2025-09-06 09:46:12 UTC
Julien Nabet committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/b5044aa84af207dc44944c9ad51847b50e7f43b1

tdf#168265: pass comment (999) section to detect dxf file

It will be available in 26.2.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.