librecad / libdxfrw Goto Github PK

followup to LibreCAD/LibreCAD#875

The referenced LibreCAD issue is caused by LEADER entities without coordinates.

Means code 76 is 0 and AutoCAD abandon loading this file. Whereas other CAD software load the file by ignoring the malicious LEADER entity. This includes latest LibreCAD.

Investigating this LibreCAD issue brought up, that libdxfrw saves code 76 twice.

While this seems not to be a serious issue, it should be fixed anyhow.

It is also indicated, that the whole LEADER entity should be dropped on writing when ent->vertnum or ent->vertexlist.size() is less than 2.
This will not solve the cause of the LibreCAD issue, but it will avoid that AutoCAD rejects the file when the issue happens.

I get 6 errors when compiling the lib on my Mac .

[ 95%] Building CXX object CMakeFiles/dxfrw.dir/src/libdxfrw.cpp.o
/Users/.../libdxfrw-master/src/libdxfrw.cpp:794:27: error: no
viable conversion from
'std::__1::__vector_base<std::__1::shared_ptr<DRW_Vertex2D>,
std::__1::allocator<std::__1::shared_ptr<DRW_Vertex2D> > >::value_type'
(aka 'std::__1::shared_ptr<DRW_Vertex2D>') to 'DRW_Vertex2D *'
DRW_Vertex2D *v = ent->vertlist.at(i);
^ ~~~~~~~~~~~~~~~~~~~
/Users/.../libdxfrw-master/src/libdxfrw.cpp:855:21: error: no
viable conversion from
'std::__1::__vector_base<std::__1::shared_ptr<DRW_Vertex>,
std::__1::allocator<std::__1::shared_ptr<DRW_Vertex> > >::value_type' (aka
'std::__1::shared_ptr<DRW_Vertex>') to 'DRW_Vertex *'
DRW_Vertex *v = ent->vertlist.at(i);
^ ~~~~~~~~~~~~~~~~~~~
/Users/.../libdxfrw-master/src/libdxfrw.cpp:926:24: error: no
viable conversion from
'std::__1::__vector_base<std::__1::shared_ptr<DRW_Coord>,
std::__1::allocator<std::__1::shared_ptr<DRW_Coord> > >::value_type' (aka
'std::__1::shared_ptr<DRW_Coord>') to 'DRW_Coord *'
DRW_Coord *crd = ent->controllist.at(i);
^ ~~~~~~~~~~~~~~~~~~~~~~
/Users/.../libdxfrw-master/src/libdxfrw.cpp:955:28: error: no
viable conversion from
'std::__1::__vector_base<std::__1::shared_ptr<DRW_HatchLoop>,
std::__1::allocator<std::__1::shared_ptr<DRW_HatchLoop> > >::value_type'
(aka 'std::__1::shared_ptr<DRW_HatchLoop>') to 'DRW_HatchLoop *'
DRW_HatchLoop *loop = ent->looplist.at(i);
^ ~~~~~~~~~~~~~~~~~~~
/Users/.../libdxfrw-master/src/libdxfrw.cpp:1041:24: error: no
viable conversion from
'std::__1::__vector_base<std::__1::shared_ptr<DRW_Coord>,
std::__1::allocator<std::__1::shared_ptr<DRW_Coord> > >::value_type' (aka
'std::__1::shared_ptr<DRW_Coord>') to 'DRW_Coord *'
DRW_Coord *vert = ent->vertexlist.at(i);
^ ~~~~~~~~~~~~~~~~~~~~~
/Users/.../libdxfrw-master/src/libdxfrw.cpp:2573:30: error:
reference to type 'const std::shared_ptr<DRW_Vertex>' could not bind to an
lvalue of type 'DRW_Vertex *'
pl->appendVertex(v);
^
/Users/.../libdxfrw-master/src/drw_entities.h:757:56: note:
passing argument to parameter 'v' here
void appendVertex (std::shared_ptr<DRW_Vertex> const& v) {
^
6 errors generated.
make[2]: *** [CMakeFiles/dxfrw.dir/src/libdxfrw.cpp.o] Error 1
make[1]: *** [CMakeFiles/dxfrw.dir/all] Error 2
make: *** [all] Error 2

I use QCadCam software to create a DXF file about CAM, and this DXF file contains some cam-related data, some of the data is in the block entity, and then I use dxflib to read this DXF file, the addXDataString() interface is used to retrieve CAM data from block entity, but use libdxfrw to read DXF file, DRW_Block.extData.size () is 0, why?

I have recently created the DimArc tool.

It saves very well in various image formats, as well as the PDF format, but unfortunately, it does not get saved into the DXF file.

Because AutoCAD has the same tool, I assumed that the standard DXF format would accommodate such a feature;
but it does not. I read the DXF format's specification, and it says nothing about DimArc.

So, it would be great if a specification is defined and implemented, that would complete the DimArc tool.

Its variables are are follows:

• Definition point
• DimArc centre point
• DimArc radius
• DimArc start angle
• DimArc end angle

I believe either the definition point or the start angle can be made redundant.

Also, if anybody is working on it, it would also be great to look into saving a DimCurve,
another feature found in AutoCAD.

I know the encoding of this dwg file is in GBK or gb2312 ，But I cannot export dxf (v2007) correctly using the program, and I cannot even export any version correctly. It is interesting that using AutoCAD can correctly export UTF-8 format dxf without garbled text.
Please help me！In fact, aspose.cad provides a Java/. net version for exporting dxf files, but its format can only be exported as dxf-R12 version. I want dxf-v2007 version or higher to support gbk (Chinese).

It is very interesting that the converted dxf file cannot be opened by AutoCAD software, but can be opened by third-party software as follows. I guess when reading in, I should use GBK to read dwg and write in dxf (v2007), I should use UTF-8 to write in, so he needs a conversion, but I don't know how to modify it

The Test File
a-43.zip

When I ran dxf2dwg to convert dwg to dxf, there seemed to be some lines and layers that were not loaded. Is it because the library currently does not fully support converting dwg to dxf?

I wrote the following extended data according to the requirements of DRW_Variant format

1001, "SAG_CURVE"
1002, "{"
1003, "0"
1000, "woaini"
1000, "520"
1000, "This is a circle." "
1071, 0
1071,1
1040,37.5
1040,43.6
1002, "}"
Before the bool dxfRW:: write Entity (DRW_Entity * ent) function finally returns, add the following code:
if (!ent->extData.empty()){
writeExtData(ent->extData);
}
In the inheritance implementation class of DRW_Interface QinWriter, adding the corresponding code to write the extended data above, the graphics can be drawn, but check the DXF file, there is no section at the beginning of 1001, which senior programer knows what's going on, can you give me some advice?

I use AutoCAD to draw a random drawing and save it as DWG. The DXF file generated by running DWG 2dxf cannot be opened by AutoCAD. If you open it with notpad + +, you will see a lot of black "NUL". There is no such "NUL" in DXF generated by AutoCAD.

BOSS Can you support Chinese

Cppcheck warns that this code leads to a dead end.

Looks like because of this line

cp has been uppercased at the beginning of the method, so comparing it against lower-cased strings will probably not match. Happens in L514 to L520.

Issue #56 fixed error loading the file: camotes-dwg.zip
But now there remains a regression against 0.6.3 that all the text is no longer show:

0.6.3 did load it incl. fonts:

Since the writePolyline function is missing the vertex subclass mark 100 "AcDb3dPolylineVertex", autoCAD opened the generated DXF with an error: the file is incomplete. I added writer->writeString(100,"AcDb3dPolylineVertex") under line 817 of the libdxfrw.cpp file, and then opened it with autoCAD without an error.

like this:

best regard!

As reported on #librecad IRC channel, this happens with a malicious auto save DXF file.
When ENDSEC code is missing at the end of the DXF file LibreCAD hangs on opening the file.
So the reader must report an error, but should not crash the application.

Hi all, I have, stumbled across this feature. I am reading a DXF and converting all possible entities into lines or polylines. However some of the arcs are reversed. When I debug, I realised isccw is being set to 1 while creating an arc on reader.

Do you have an idea how I can determine if an arc is ccw or not?

When converting the file Ceco.NET-Architecture-Tm-271.dwg obtained from here
with dwg2dxf 1.0.1
it consumes memory at a rate of 1GB every 5 seconds or so and appears to have no limit (I killed it after 40GB)

The mentioned method seems bugged:

The member dxfReader::type is set before call to readInt16(), which overwrites dxfReader::type. Therefore enum member INT64 will never be used, thus the member dxfReader::int64 has no use.

EDIT: Are codes 160 to 169, which require reading 64 bit integers, even used or supported by the ASCII DXF format?

I'd like to forward some patches from qgis external copy of libdxfrw (eg qgis/QGIS#44428), but I'd like clarification on whether this repo or https://github.com/codelibs/libdxfrw would be the best place to do this.

Ideally these three maintained forks could be unified into one upstream. Is there general interest for this?

This link is broken:

https://github.com/LibreCAD/LibreCAD_3/tree/master/lcDXFDWG/lcDXF

This includes :

• export cmake target
• cmake installation
• conan package
• manual for packagers
• FindLibdxfrw.cmake

I've confirmed that dwg2dxf was able to generate a dxf file without issues with libdxfrw 0.6.3 (and older librecad builds against 0.6.3 loaded it as well), but with the upgrade to 1.0.1 (current HEAD code), neither dwg2dxf nor librecad (tested with 2.2.0rc2 and 2.2.0rc3 built against libdxfrw HEAD) can open the dxf file at issue.

[spot@localhost libdxfrw]$ file ~/sandbox/camotes.dwg
/home/spot/sandbox/camotes.dwg: DWG AutoDesk AutoCAD 2007/2008/2009

camotes-dwg.zip
[spot@localhost libdxfrw]$ dwg2dxf ~/sandbox/camotes.dwg -v2010 ~/sandbox/camotes.dxf
DWG file error: format 15 error 9
Error reading file /home/spot/sandbox/camotes.dwg

Conversion failed

Problematic DWG file attached to this issue (inside a ZIP to pacify GitHub). Happy to help debug here, but I'm not sure where to start.