Changes between Version 8 and Version 12 of Ticket #4369


Ignore:
Timestamp:
Oct 31, 2017, 7:54:54 PM (6 years ago)
Author:
Alan Thomas
Comment:

Many of these issues have recently been solved. For the remaining issues, I've split this ticket into several new tickets which can then be handled individually.

In view of the fact that the reporter has disappeared, there is no longer anything to do here, so I am closing this ticket.

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #4369

    • Property Status assigned → closed
    • Property Resolution → invalid

  • Ticket #4369 – Description

    v8 v12  
    66    - The width-scaling of the text ("Relative X scale factor") is now stored as style string (param_name: "w")
    77
    8 TranslateDIMENSION
     8TranslateDIMENSION **dealt with in #7120**
    99    - The text angle is calculated with atan instead of atan2. This prevents the text beeing written upside down.
    1010    - The arrowheads are now scaled according to the arrow head size given in the header section of the DXF-file.
    … …  
    1313
    1414New DXF-Entities are supported:
    15         - TranslateLEADER
    16         - TranslateSOLID (at this point only the a border around the solid is drawn, i.e. no filling!)
     15        - TranslateLEADER **dealt with in #7111**
     16        - TranslateSOLID (at this point only the a border around the solid is drawn, i.e. no filling!) **dealt with in #5380**
    1717
    1818PrepareLineStyle
    19      - A layer color value of "0" in DXF files means that the color of the entity is determined by the superior block. In case we do not inlined blocks this information ("BYBLOCK") is passed as style string of the pen color instead of the RGB-color code. (i.e. PEN(c:BYBLOCK) instead of for example PEN(c:#FF0000) )
     19     - A layer color value of "0" in DXF files means that the color of the entity is determined by the superior block. In case we do not inlined blocks this information ("BYBLOCK") is passed as style string of the pen color instead of the RGB-color code. (i.e. PEN(c:BYBLOCK) instead of for example PEN(c:#FF0000) ) **dealt with in #7099 (in a different way - the colour of the block is propagated onto those objects on layer 0 within the block, instead of storing BYBLOCK and making the end user select the right colour, which might be impossible if there are no other objects on the layer on which the block is inserted)**
    2020
    2121Added new attributes for features:
    22         - "PaperSpace" -> Absent or "0" means model space, "1" means paper space.
    23         - "Invisible" -> Indicates the object visibility: "0" = visible, "1" = invisible
    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".
     22        - "PaperSpace" -> Absent or "0" means model space, "1" means paper space. **split out to #7121**
     23        - "Invisible" -> Indicates the object visibility: "0" = visible, "1" = invisible **split out to #7121**
     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".**dealt with in #7106 using different field names**
    2525
    2626ACTextUnescape
    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"
    28 .
    29 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.)
     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.) **split out to #7122**
    3028
    3129I think that were all or at least the most important changes I have made. Because this is my first ticket, I hope I made no serious mistake and the changes in the patch are GDAL-conform. I would be pleased if the changes would be incorporated into trunk and finally into the next GDAL release.