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
Created attachment 202673 [details] Sample DXF file without top comments
Created attachment 202674 [details] Sample DXF file with top comments
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.
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
(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
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.
Julien Nabet committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/1d6298f1c64a8ba6c6634335960d2b247d0d2f30 Related tdf#168265: fix DXFGroupReader::ReadF 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.
Julien Nabet committed a patch related to this issue. It has been pushed to "libreoffice-25-8": https://git.libreoffice.org/core/commit/f9eacf3d535e3dac7c1f30a5f74f4ff7a77a94be tdf#168265: pass comment (999) section to detect dxf file It will be available in 25.8.2. 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.
Julien Nabet committed a patch related to this issue. It has been pushed to "libreoffice-25-8": https://git.libreoffice.org/core/commit/5389294d747f8ca3d964f126cab627eb89c4ec91 Related tdf#168265: fix DXFGroupReader::ReadF It will be available in 25.8.2. 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.
Xisco Fauli committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/b4f7879d277247734bbe7335cfa56a66db815df1 tdf#168265: vcl_graphic_test: Add test 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.
Julien Nabet committed a patch related to this issue. It has been pushed to "libreoffice-25-2": https://git.libreoffice.org/core/commit/f4ab2874ca9782283f3a09329fdb5c6781b5a3ab tdf#168265: pass comment (999) section to detect dxf file It will be available in 25.2.7. 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.
Julien Nabet committed a patch related to this issue. It has been pushed to "libreoffice-25-2": https://git.libreoffice.org/core/commit/2a16a922c4b78850375def4bc5dfecd11d87e1d7 Related tdf#168265: fix DXFGroupReader::ReadF It will be available in 25.2.7. 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.
The bug is resolved, but only if the DXF file contains a single comment on top. The following cases are still unresolved. Case 1: The DXF file contains more than one comment on top, like this: 999 Comment one 999 Comment two - the file is opened in Writer, but in version 7.4.7.2 is opened as expected in Draw - if i drag and drop that file on a Draw or Writer page, it is recognized as a drawing So looks like there is a different logic between Open and Drag and Drop. Case 2: The DXF file contains comments not on top - LibreOffice throw the following two errors and doesn't open the file at all Warning Image filter not found [OK] Error General Error. General input/output error. [OK] This is a case that I have never encountered but it might affect someone else.
(In reply to Gianni from comment #13) > The bug is resolved, but only if the DXF file contains a single comment on > top. > ... I've submitted this patch: https://gerrit.libreoffice.org/c/core/+/190865 it takes into account: 1) that the file may contain more than 1 comment at the beginning 2) that a file may contain 1 comment at another location that the beginning Remnant pb: format detection takes the 256 first characters so if comments at the beginning take more than 256 characters ("999" labels + newlines included), the file will be opened in Writer. Ideally, we should try to read more than 256 characters if needed.
Julien Nabet committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/829f59de4e44a5a2c9888e7ceef439809808f2c0 Related tdf#168265: ignore more comments line 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.
I must apologize. When I tested a DXF file with comments not on top, I placed the comment in the wrong place, not beginning on an odd row: this bug never existed at all in any LibreOffice version I tested. So the bug is only for comments on top. With your latest patch, a DXF file with up to three consecutive comments on top, opens as expected in Draw. But from four and up, it opens in Writer. This limit doesn't exist for comments not on top. 999 This is the comment line one 999 This is the comment line two 999 This is the comment line three 999 This is the comment line four I confirm a different logic between Open and Drag and Drop, because the latter never had a problem.
(In reply to Gianni from comment #16) > ... > This limit doesn't exist for comments not on top. > Yes because the 256 characters limitation is only about detection of the beginning of the file. Once LO understands it's dxf, there's no pb about comment lines. > 999 > This is the comment line one > 999 > This is the comment line two > 999 > This is the comment line three > 999 > This is the comment line four No, if the file begins with: 1 999 2 This is the comment line one 3 999 4 This is the comment line two 5 999 6 This is the comment line three 7 999 8 This is the comment line four 9 999 10 This is the comment line five 11 0 12 SECTION 13 2 it works. As I said, LO will try only the 255 first characters for detection so it depends on the length of comments. >...
But in version 7.4.7.2 this limit doesn't exist. Neither using Drap and Drop on a Draw or Writer page in any version, also in the latest daily.
(In reply to Gianni from comment #18) > But in version 7.4.7.2 this limit doesn't exist. > > Neither using Drap and Drop on a Draw or Writer page in any version, also in > the latest daily. Yes it's because before https://gerrit.libreoffice.org/c/core/+/137935 patch, the detection was made only on the extension of the file (has the file "dxf" extension). So there wasn't this 256 characters limit on detection. Tomaž/offtkp: don't hesitate to comment here.
(In reply to Julien Nabet from comment #19) > Yes it's because before https://gerrit.libreoffice.org/c/core/+/137935 patch, > the detection was made only on the extension of the file > (has the file "dxf" extension). > So there wasn't this 256 characters limit on detection. Ok. So Drag and Drop is using the old detection? Is there a particular reason for having two distinct detection modes?
(In reply to Gianni from comment #20) > ... > So Drag and Drop is using the old detection? I don't know how drag and drop works.
Julien Nabet committed a patch related to this issue. It has been pushed to "libreoffice-25-8": https://git.libreoffice.org/core/commit/cb8bf48260a43895cbb5b1c51e13ce9cdf53e69b Related tdf#168265: ignore more comments line It will be available in 25.8.2. 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.
(In reply to Julien Nabet from comment #19) > > Yes it's because before https://gerrit.libreoffice.org/c/core/+/137935 > patch, the detection was made only on the extension of the file (has the > file "dxf" extension). So there wasn't this 256 characters limit on > detection. > Why was this new feature introduced? Perhaps because the file extension logic can't be used on some platforms? But if I'm on a platform that can already tell me what file it is via the file extension, why not take that into account and avoid the analysis of the file content, which in this specific case turns out to be somewhat inaccurate? However, despite these considerations, the bug is fixed.
(In reply to Gianni from comment #23) > ... > Why was this new feature introduced? > Perhaps because the file extension logic can't be used on some platforms? > > But if I'm on a platform that can already tell me what file it is via the > file extension, why not take that into account and avoid the analysis of the > file content, which in this specific case turns out to be somewhat > inaccurate? > ... I don't know, perhaps Tomaž or offtkp may answer.
The commit message states clearly why this was added: we had 2 implementations of image format detection so we combined that into one to remove duplication. For DXF we previously relied only on the extension in one detector, while the other detector had an implementation that actually tried to detect the image format, so we used that. Unfortunately that had flaws which we were not aware of, but then the image format that can't be quickly identified is also flawed by itself but those are rare (however I think even PDF can have a comment before the identificator "%PDF", which is the similar to DXF in a way and many apps don't take that into account). There is no platform that guarantees that the extension reflects the content, so those are generally not trusted by applications - not even on Windows (but are for at least which applications to start for an extension). Even MS applications like MS Office doesn't blindly trust the extensions to identify what the image format is. Say you have a PNG image and change the extension to .JPG, MS Office will have no problem adding that file to the document, but relying on an extension it should, because that image should've gone to the JPEG decoder instead of PNG decoder, where it should've failed. That doesn't happen.