Changes between Initial Version and Version 2 of Ticket #4369


Ignore:
Timestamp:
Dec 6, 2011, 3:37:57 PM (12 years ago)
Author:
srock
Comment:

Replying to rouault:

This belongs to FrankW's area of expertise, but I did try to read the patch and was stopped by its unreadability as a patch. I guess there must have issues with your text editor messing with end of line characters, or something like that, but if you look at http://trac.osgeo.org/gdal/attachment/ticket/4369/gdal-ogr-dxf-20111205.patch, you'll see that is impossible to know if you have indeed rewritten everything, or if your changes are more local. I also observe strange indentations, perhaps due to the use of tab characters ?

I'm sorry, there was indeed a problem with tab characters and end of line characters. I removed all tab characters and changed the end of line characters to UNIX format. I think now it looks better. I have uploaded the fixed patch again as a replacement for the previous one. I have also corrected some typos in the description above.

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #4369 – Description

    initial v2  
    22
    33Here is a summary of what I have done:
     4
    45TranslateTEXT
    56        - The width-scaling of the text ("Relative X scale factor") is now stored as style string (param_name: "w")
    … …  
    910        - The arrowheads are now scaled according to the arrow head size given in the header section of the DXF-file.
    1011        - Added support for radius and diameter dimension types.
    11         - If we do not inlined blocks, the only the reference to the according block (where the dimension picture is stored) is capured on a point feature. It is therefore not necessary to compute new lines and arrows for each different dimension type. (In relation to this also the new feature attribute "BlockReference" is important, see below!)
     12        - If we do not inlined blocks, only the reference to the according block (where the dimension picture is stored) is captured on a point feature. It is therefore not necessary to compute new lines and arrows for each different dimension type. (In relation to this also the new feature attribute "BlockReference" is important, see below!)
    1213
    1314New DXF-Entities are supported:
    … …  
    2122        - "PaperSpace" -> Absent or "0" means model space, "1" means paper space.
    2223        - "Invisible" -> Indicates the object visibility: "0" = visible, "1" = invisible
    23         - "BlockReference" -> This is now used in combination with "BlockName" in case we do not inlined blocks. Before it was not possible to find the entities which belonged to a certain block reference (if one block was part of another block), because the block reference (to another block) was overwritten (in GetNextUnfilteredFeature) with the name of the block the block reference was part of. Now the names of the blocks (defined in the BLOCKS Section of the DXF file) is stored in "BlockName" and the reference to a block (these references are part of an INSERT or a DIMENSION) are stored in "BlockReference".
     24        - "BlockReference" -> This is now used in combination with "BlockName" in case we do not inlined blocks. Before it was not possible to find the entities which belonged to a certain block reference (if one block was part of another block), because the block reference (to another block) was overwritten (in GetNextUnfilteredFeature) with the name of the block the reference was part of. Now the names of the blocks (defined in the BLOCKS Section of the DXF file) is stored in "BlockName" and the reference to a block (these references are part of an INSERT or a DIMENSION) are stored in "BlockReference".
    2425       
    2526ACTextUnescape
    26         - In this function some DXF escape sequences are translated and stored into a resulting string. At the moment not all possible sequences are translated. Some of the possible sequences have to do with the formating (of somtimes only parts) of the text, like color codes, italic, font descriptions, etc. I don't think that it is not allways usefull to remove these kind of informations. (For instance I am using most of the formating informations in a DXF viewer. Without the formating information I could not display the text in the correct way.) Therefore I have introduced the new config option "DXF_TRANSLATE_ESCAPE_SEQUENCES". Setting this option to FALSE prevents the translation. In the future maybe it would make sense to translate only those escape sequences, which deal e.g. with UTF8 escape sequences. (I think I have found the meaning of all the escape sequences possible in DXF files. I could post them here or on gdal-dev mailing list if someone is interested.)
     27        - In this function some DXF escape sequences are translated and stored into a resulting string. At the moment not all possible sequences are translated. Some of the possible sequences have to do with the formating (of somtimes only parts) of the text, like color codes, italic, font descriptions, etc. I think that it is not always useful to remove these kind of informations. (For instance I am using most of the formating informations in a DXF viewer. Without the formating information I could not display the text in the correct way.) Therefore I have introduced the new config option "DXF_TRANSLATE_ESCAPE_SEQUENCES". Setting this option to FALSE prevents the translation. In the future maybe it would make sense to translate only those escape sequences, which deal e.g. with UTF8. (I think I have found the meaning of all the escape sequences possible in DXF files. I could post them here or on gdal-dev mailing list if someone is interested.)
    2728       
    2829I think that were all or at least the most important changes I have made.