The Change Log of AX2020 is updated on a release basis. It follows the funnel of our online bug posting system Mantishub.
If you cannot find the support information that you are looking for, please contact us.
AX2020 Change Log
Summary |
Description |
|
20.02.09 |
||
| White Space at Top and Bottom | There is white space at the top and bottom of some drawings in PDF. | |
| Image Brightness Not Working | Setting Image Brightness is not working. The image is not modified and comes out in "normal" brightness (50%) always. | |
| SVG Overlapping Circles Display Wrong | In SVG overlapping filled
circles are displayed with weird white areas in parts of the circles. This is caused by defining the circles using one element so they follow the "winding rule" to fill the single element. Breaking the SVG path into multiple entities breaks the use of the "winding rule" and the circles are displayed correctly. |
|
| Line Styles Not Output in PDF | Line Styles are not output in PDF files. All lines come out as continuous (solid). | |
| Image not rotated | Rotating image in DXF does not
come out as rotated. Only in 90degrees increments. Images need to be able to be rotated at any rotation amount. |
|
| Need ability to alter brightness of images | Need the ability to alter the brightness setting for images. A new parameter will be added to allow the user to shift the brightness setting up or down. | |
| Text too wide | The text is too wide because the font is being substituted incorrectly. Need to define "fall back" text (generic font family) to use if the actual text font is not on the output system. | |
| Text is outside circles | Center justified text ends up outside the enclosing geometry, in this case, circles. The conversion from center to left justification is not done correctly, probably due to incorrect text height (and hence, text width) calculation. | |
| Text is too small | Certain text is too small. | |
| DWG is missing circles | SVG output is missing circles in some instances. SVG file just has a series of move commands without the subsequent draw commands. | |
| DWG-->PNG with -bw does not produce black & white output | A customer is requesting black
& white thumbnails (PNG) of drawings. When I tried to convert
DWG-->PNG with the -bw parameter specified, the output PNG is still in
color. I tried with ax2020 v20.02.06 and ax2019 v19.05.16. Both resulted in a color PNG. |
|
| DWG files not rendered correctly as PDF | We have found dwg files which
are not rendered correctly as PDF. Can you please take a look at them ?
I attached the original DWG files with the PDF created by your software. |
|
20.02.04 |
||
| XRef not included when DWG filename includes Norwegian characters (Linux)B19B17A15:B18A15:B18A15:B19A15:B20 | Using ax2020 v20.02.03 on Linux,
the Substation-ÆØÅ-xref.dwg XRef is not included in the PDF output file.
Works on Windows v20.02.03. |
|
| DWF-->PNG has black background | When I convert DWF to PNG with ax2020 v20.02.03 (Windows or Linux), the background is black even though the -b=1 parameter is used to force a white background. As a result, you sometimes can't see any of the drawing contents. | |
| Error converting valve01.dwf to PDF or PNG on Linux with v20.02.03 | The following error is displayed
when trying to convert valve01.dwf to PDF or PNG using ax2020 v20.02.03 Linux: terminate called after throwing an instance of 'OdError' Aborted |
|
| AX2020: Raster References with Norwegian characters in filename are not included in PDF | Tested with: - AX2020 v20.02.00b – Windows - AX2020 v20_01.07b – Linux Test File: A110_ÆOÅ_PRMTCA01_73.dwg & A110_ÆOÅ_PRMTCA01_73.tif When converting this drawing to PDF, the TIFF reference file is not found when its name includes Norwegian characters. NOTE: I had to create the PDF file without these Norwegian characters. - If the output file is “A110_ ÆOÅ _PRMTCA01_73-W32_20_02_00b.pdf”, the PDF is created as “A110_”. - If the output file is “ÆOÅ _PRMTCA01_73-W32_20_02_00b.pdf”, ax2020 crashes. Not sure if this part is a bug or a side effect of my environment. However, I think it should be able to find the TIFF file. |
|
| Add Fonts Directory | By default, make FontPath processing check the ./fonts subdirectory under the executable directory. This is in addition to the current spots of the executable directory and the drawing file directory. | |
20.02.03 |
||
| Memory Leaks | There are various memory leaks as shown by valgrind. Some of these leaks are in OpenDesign code and cannot be fixed by us (they will be reported) but some are in our code. | |
| Problem with Layout page sizes in PDF using -basic | Tested with: - AX2020 v20.01.07b - Linux - AX2020 v20.02.00b - Windows When converting DWG to PDF using the -basic parameter, the layout pages in the PDF are incorrectly sized. Test files: - SiteLayoutPlan.dwg - Looks much worse on Windows, but even on Linux, pages 3 & 5 have extra white space at the top and bottom of the page. On Windows, there is a lot of extra white space to the left and right on pages 2-5. I've attached the PDF generated from Linux v19.04.13 where all pages look good. Also, notice the size of the ax2019 PDF (9MB) compared to the sizes generated with ax2020 (21MB & 26MB). Why the big difference? |
|
| Polyline widths not converting correctly | Two point polylines with width explicit widths are being converted like normal lines, ignoring the polyline width value and using the default line weight value instead. | |
| Layer Off and Layer On do not work | The Layer Off (-LOFF) and Layer On (-LON) Parameters do not work. | |
| Embedded PNGs do not convert | Embedded rasters in PNG format do not convert. TIFF and JPG files work . | |
| Points Too Bulky | Points in SVG are too large and are not round. | |
20.02.02 |
||
| Default width lines too faint | AutoCAD Default width lines are too faint in SVG. | |
| Need a Linux version build with the 2020.2 toolkit (v20.02.xx) | When we release our software on
both Linux and Windows, we would like them to use the same version of the toolkit. Right now we have: AX2020 v20.01.07b - Linux AX2020 v20.02.00b - Windows |
|
20.02.01 |
||
| SHX fonts with no file extension fail | SHX fonts with no file extension in the file name do not work. They are tried to be processed like TTF files and the TTF file is not found. | |
| TIFF reference is not included in PDF | Tieto/Orsted opened a ticket
with Formtek today reporting that the TIFF reference is not included in the
generated PDF file. I have reproduced the problem with ax2020 v20.01.05 on Windows. The files are attached. |
|
| White-colored geometry is missing in PDF | Tested with: - AX2020 v20.01.07 - Linux & Windows When I convert 0BCE05EY004.dwg & 0BCE05EY004.tif to PDF, I can't see the DWG content in the PDF. The geometry in the DWG is white. |
|
| Black-colored geometry missing on layouts with -basic | Tested with: - Ax2020 v20_01_07a - Linux - AX2020 v20_02_00a - Windows When converting to PDF using -basic, the black-colored geometry is missing (or can't be seen) in the PDF. Test files: - A110_PRMTCA01_73.dwg & A110_PRMTCA01_73.tif - Substation.dwg & Substation-xref.dwg It is more obvious with Substation because the layout page in the PDF DOES shown the yellow/orange geometry. |
|
| AX2020 crashes while converting to PNG | Tested with: - AX2020 v20_01_07 - Linux & Windows Converting to PNG crashes the ax2020 on both Linux and Windows. On Linux, the following is displayed: Error: signal 11: ./ax2020_L64_20_01_07(_Z17seg_fault_handleri+0x1c)[0x54a3a0] /lib64/libc.so.6(+0x36280)[0x7f38b6111280] ./ax2020_L64_20_01_07[0x57848d] ./ax2020_L64_20_01_07[0x6459ea] ./ax2020_L64_20_01_07[0x64e5ef] ./ax2020_L64_20_01_07[0x54bc74] /lib64/libc.so.6(__libc_start_main+0xf5)[0x7f38b60fd3d5] ./ax2020_L64_20_01_07[0x54a2c9] |
|
20.02.00 |
||
| White Filled Areas Output as Black | White Filled Areas Output as Black | |
| Upgrade to OpenDesign V2020.1 | Upgrade to OpenDesign V2020.1 | |
20.01.06 |
||
| Raster Clipping Boundary not Respected in PDF output | The PDF from the command below
generates a PDF with part of the image outside of the clipping boundary. The drawing and PDF are attached. .\ax2020_W32_20_01_00 -i="C:\downloads\Drawings\Raster References\A110\A110_PRMTCA01_71.dwg" -o="C:\downloads\Drawings\Raster References\A110\A110_PRMTCA01_71-20_01_00.pdf" -f=pdf -basic -REPO -NUI -fontpath="C:\Program Files\Autodesk\AutoCAD 2020\Fonts" AutoXchange 2020 V20.01.00 Copyright (c) 2017, 2018, 2019 Tailor Made Software, Ltd. All Rights Reserved Portions Copyright (c) 1997-2016, Tailor Made Software, Ltd. ============================================================ Input File Name: C:\downloads\Drawings\Raster References\A110\A110_PRMTCA01_71.dwg Output File Name: C:\downloads\Drawings\Raster References\A110\A110_PRMTCA01_71-20_01_00.pdf Layout Name: Layout1 Drawing Width: 2500 Drawing Height: 1414 View Name: ModelSpace Font Name: arial Define Font: arial Drawing Width: 2500 Drawing Height: 1618 Elapsed Time: 1.511 seconds --- "Patty Hodgson" <phodgson@formtek.com> |
|
| ax2020 v20.01.05: Some DWFs fail to create a valid PDF | The following DWF files do not
create a valid PDF file in ax2020 v20.01.05: - AEMF2A2.dwf - AEMF457.dwf - Map2Globe San Rafael-Rio and Indonesia.dwf - nakladac.dwf However, these do work: - IRD Addition.dwf (though some fonts aren't found) - mikado.dwf - wing.dwf All of these worked in ax2019 v19_01_16, which it the version we bundled in our last software release. We'd like to upgrade to ax2020 in our next release but conversions should improve (or stay the same), not get worse. |
|
| Optimize Points in SVG | The output of points in SVG always uses absolute coordinates. This takes more size than using relative coordinates for small differences between points. Use relative coordinates if the x and y offsets are less than 100 units. | |
| Circles Not Filled | Circles are not filled if needed. It is common to use a two point polyline with width in AutoCAD to produce a filled circle. This needs to be mapped to a filled circle. | |
| Converting a single view to SVG adds other views to Pages list | When converting just Modelspace
to SVG it results in extra pages representing any Layouts being added to the
Pages array in the SVG file. This might or might not be the desired conduct.
Need to add a new parameter to not add the Layout Names to the Pages list in
the SVG file. New parameter -modelonly is added. This will convert the ModelSpace to SVG but will not add any other pages to the Pages list. |
|
| Layout Model does not convert | If the user requests the
conversion of -Layout="Model" the converter will not function
properly. Strictly speaking Layouts are Paperspace features and Model is not
relevant. Add functionality to recognize -Layout="Model" and -Layout="ModelSpace" and convert as if -model was used instead. |
|
20.01.04 |
||
| Layout on DWF Import Crashes | Defining a layout to convert when the import file is DWF causes the conversion to fail and an incorrect PDF to be created. | |
20.01.03 |
||
| Leader Lines missing in PDF | The leader lines are missing in the PDF. | |
| Block Reference Information & MText Missing in PDF | Ran this command: .\ax2020_W32_20_01_02a -i="C:\downloads\Drawings\AutoCAD 2020\Sample Sheet Sets\Manufacturing\VW252-02-1600.dwg" -o="C:\downloads\Drawings\AutoCAD 2020\Sample Sheet Sets\Manufacturing\VW252-02-1600-20_01_02a.pdf" -f=pdf -basic -REPO -NUI -fontpath="C:\Program Files\Autodesk\AutoCAD 2020\Fonts" The PDF is missing block data as well as multiline text (MText) not in blocks. Drawing and PDF are attached. |
|
20.01.02 |
||
| Unicode text not selectable in PDF | Unicode text not selectable in PDF. | |
20.01.01 |
||
| DWG->SVG: Extents in drawing not properly calculated | The viewbox is much smaller than the usual extents, see: viewBox="0 0 472.207 334" , therefore all lines ends op with a roughly factor 4 too wide. | |
20.00.03 |
||
| DWG->SVG: Line thickness of entities in SVG are excessive large - issue solved for some files, but not all | Previous reported line thickness
bug has been resolved, but for some drawings it still persists. Attached is one of our trial version drawings, where the line thickness is incorrectly calculated. See lines in red and yellow. |
|
20.00.00 |
||
| AX: POSTFIX creates same random text for two consecutive calls of AX. Happens randomly. | In CV-JS compare method, AX is
called two times in succession to make overlay drawings. For some reason, AX
seems to create the same random text for two conversions. This happens one
out of three on average. The compare method will not work unless the layers are named differently, so this bug prevents compare to work. This but is consistent over previous versions, attached SVG is using AX2019wPDF_W32_19_05_22.exe, where that version has an issue with line width over many files. |
|
19.05.22 |
||
| DWG->SVG: Thickness of entities in SVG are excessive, lines towards an origo | Attached chinese reference file, some objects on modelspace, layout 1 +2, simply fills the canvas with gray blobs. Could be the old line weight issue that manifests itself in a different drawing? Lines are seen towards an origo, could be similar to Orsted logo. | |
19.05.20 |
||
| Watermarks: No color parameter defined | For watermarks, setting the
color is very important, but for the described interface (not working at the
time), there is no color parameter included. Resolution There are two new parameters: -wm_color – use AutoCAD Color Index (1-255) -wm_rgb – use (nnn,nnn,nnn) where each Red/Green/Blue value nnn is between 0 and 255 |
|
| Watermark: output on SVG but location/size wrong | Watermarks: DWG->SVG/PDF -wm_xpos="80%" -wm_ypos="20%"
-wm_size="10%" , output on SVG but location/size wrong AX2019wPDF_W32_19_05_17 -i=City_map.dwg -o=City_map_water_percent.svg -f=svg -basic -trace -wm_content="Hello World" -wm_xpos="80%" -wm_ypos="20%" -wm_size="10%" Calculation is done testing with SVG, but both insertion point and size of content is completely off, therefore no visual content. Likely same with PDF. <g id="layer_0" class="layer_0" cvjs:layerName="0" cvjs:status="ON" visibility="visible"> <g style="font-family:'ARIAL'; stroke:none; fill:black ;" > <g font-size="0.839235" > <text id="cv_415" x="2500" y="1804.79" >Hello World</text> </g> Resolution Position is changed. Note, however, that size must be in absolute DWG values, not percentages. |
|
19.05.19 |
||
| PDF Line Thickness Is Wrong | All lines in PDF are the same thickness even though different line thicknesses are set in the drawing. | |
| DWG->SVG: Frame border element got exceeding width | In view on CV-JS download
samples reference drawing, the frame suddenly has an exceedingly
line-width. May be related to previously submitted bug report on OpenKM customer drawing. |
|
| PDF Closed Polygons Not Closed | Closed Polygons output to PDF need the closed flag set. | |
19.05.18 |
||
| Transcode issue, AX2019 unable to parse RM$ and RM$TXT on Linux | rl/tl not able to parse a
layername with $ in it on Linux. Had
to rename to _ to make things work. RESOLUTION The linux bash shell treats any command line string beginning with a $ as an environment variable. For instance, $HOME is replaced with /usr/<user> where <user> is typically the user name. On my system that would be /usr/scott, the root directory for my username. In order to use a dollar sign you must substitute it in the same manner that spaces are substituted (although they can be used directly by enclosing the string in quotes, so it is not exactly the same). So use %20 for spaces and use %24 for dollar signs. So RM$TXT would be RM%24TXT. This substitution is not needed if the $ is the last character, so RM$ works, but RM$TXT does not. Putting the string in quotes ("RM$TXT") does not help. The full list of substitutes are: %20 <space> %21 ! %22 " %23 # %24 $ %25 % %26 & %27 ' %28 ( %29 ) |
|
| DWG->SVG : AX seems to have lost the ability to remove small text objects in conversion when font-size is very small. | The snap toolkit has an issue
with very small rotated text objects which gives an wrong extent. We wrote an
algorithm in AX that would remove text object below a given threshold. This
capability seems lost on the attached file. The small text objects can be on a
layer or in a block definition it seems There should also be a parameter to remove any text below a given % of extents, and/or to stroke text out below a given threshold. Layer: <g id="layer_CIG_CHI_32_CURRENT_121318_CIG_CHI_32_FL_Proposed_BP_020817_0_CIG_CHI_32nd_Fl_CURRENT_R_041316_0_A_FURN_P_WKSF_T" class="layer_CIG_CHI_32_CURRENT_121318_CIG_CHI_32_FL_Proposed_BP_020817_0_CIG_CHI_32nd_Fl_CURRENT_R_041316_0_A_FURN_P_WKSF_T" cvjs:layerName="CIG_CHI_32_CURRENT_121318|CIG_CHI_32 FL_Proposed BP_020817$0$CIG_CHI_32nd Fl_CURRENT R_041316$0$A-FURN-P-WKSF-T" cvjs:status="ON" visibility="visible"> <g style="font-family:'archquik'; stroke:none; fill:red;" > <g font-size="0.00133631" > <text id="cv_404" x="1983.57" y="2379.89" transform="rotate(180 1983.57 2379.89) ">XWIS2496</text> Block: <g id="layer_wbx_CIG_CHI_32_CURRENT_121318_CIG_CHI_32_FL_Proposed_BP_020817_0_CIG_CHI_32nd_Fl_CURRENT_R_041316_0_A_FURN_P_WKSF_T_block" class="layer_wbx_CIG_CHI_32_CURRENT_121318_CIG_CHI_32_FL_Proposed_BP_020817_0_CIG_CHI_32nd_Fl_CURRENT_R_041316_0_A_FURN_P_WKSF_T_block" cvjs:layerName="CIG_CHI_32_CURRENT_121318|CIG_CHI_32 FL_Proposed BP_020817$0$CIG_CHI_32nd Fl_CURRENT R_041316$0$A-FURN-P-WKSF-T" cvjs:status="ON" visibility="visible"> <g class="CIG_CHI_32_CURRENT_121318" id="Block_wbx_CIG_CHI_32_CURRENT_121318_135"> <g style="font-family:'archquik'; stroke:none; fill:red;" > <g font-size="0.000599203" > <text id="cv_405" x="1983.57" y="2379.89" transform="rotate(180 1983.57 2379.89) ">STC</text> <text id="cv_406" x="1983.57" y="2379.89" transform="rotate(180 1983.57 2379.89) ">MET</text> <text id="cv_407" x="1983.57" y="2379.89" transform="rotate(180 1983.57 2379.89) ">1</text> <text id="cv_408" x="1983.57" y="2379.89" transform="rotate(180 1983.57 2379.89) ">0.000000</text> </g> |
|
| DWG->SVG , command -stroke / -st has no effect on file | Converting attached file DC-32.dwg to SVG, if using -stroke, there is no difference in file size or appearance on the output. | |
| -la area calculation command not working for -rl/-tl case. Command -la works together with -hl. | Venetian: To build demo, we need -la to function properly in the -rl/-tl case. Currently command -la works together with -hl. Demo is Tuesday , April 16, so need 24 hour response time on this to be able to build the demo. | |
| DWF->SVG+PDF , emnedded bitmap images loose accuracy/sharpness, objects becomes jagged | Rolta images change
"sharpness" in conversion.
Could be a tiff type not properly handled? See attached files. Running in 19.05.17 creates same result, with the difference that AX leaves 2 bitmap files in the folder, which are not removed after conversion |
|
| DWF -> SVG/PDF , embedded temporary files are not cleaned up after conversion | In the attached file A-108_6TH__FLOOR.dwf, AX leaves 424 temporary png files on the server after conversion. No clean-up taking place | |
| DWG->SVG: In conversion, some large letters "p" appers in converted SVG file | In CV-JS download sample file, some large letters "p" appears in the converted objects. Could be a letter size calculation that is off. | |
| DWG->SVG+PDF - some entities explode in size, thickness must be off? (looks like hatch elements) | On attached drawing, in the frame to the left, there is a large gray object. In PDF it is jagged, in SVG it is more like an oval size shape. Inspecting on 5_16, this looks like a hatch where width of objects have exploded in size. | |
19.05.17 |
||
| Special support for RL/TL based on Multiple Attributes | The Room Layer/Text Layer processing works on Attributes, Text, and MText, but the user needs it based on a combination of multiple attribute values. | |
| Invisible Attributes Should Convert to SVG | Invisible Attributes should be converted to SVG but have their visibility set to hidden. | |
| DWF->SVG: AX2019 needs two executions to create an output SVG. 1st time creates a temp png file that is used in the second run | Rolta Report: 1: Running AX2019. no svg output is created, but a single temporary png file is created 2: Running AX2019 a second time. A large set of temporary .png files are created (and not cleaned up afterwards) and an SVG output file is created. The process can be repeated. Remove the temporary files and AX2019 needs two executions to produce the output. |
|
| Transparent Embedded bitmap has black background | Rolta sample DWF drawing A-101_Ground_Floor_Plan.dwf, converting DWF->SVG, the background of the upper right bitmap is black and the bitmap itself is polluted. -cq=0, -cq=1 exhibits the black background, -cq=2 makes AX hang up. | |
| DWF->SVG : Embedded bitmap is black + embedded bitmap is "corrupted" with pixels in different colors | See attachment, issue with embedded bitmaps, background change color to black, some optimization appears to go wrong, giving a portion of the image that is cluttered with pixels different from original image. | |
| DWF->PDF: resulting pdf is 0 byte | The same Rolta reference file,
in which bitmaps converts incorrect with black background when doing
DWF->SVG, when converting
DWF->PDF the resulting PDF file is 0 byte.
|
|
19.05.16 |
||
| DWG->SVG: Line thickness of entities in SVG are excessive large in Model Space - whereas Views converts and displays correctly | DWG->SVG -> Line thickness of entities in SVG are
excessive large in Model Space. Screenshot and DWG drawing below |
|
| AX2019 stops if not a full absolute path is set in -o= | AX2019 has lost the ability to
set an output file name that is created in the current folder. C:\xampp\htdocs\cadviewer_3_2_0\converters\ax2019\windows\dev>ax2019 -i=A-001_Site_Setting_Out_Plan.dwf -o=test_1.svg -f=svg -basic Output Directory Does Not Exist: |
|
| Non-solid Hatches Do Not Convert | Non-solid hatches do not convert | |
| Suppress extra messages | The message warning that a font file is not found should only be output once per font. | |
| Ignore Xrefs where the file is not found | If an External Reference file is
not found a text is output near the origin stating the file is not found.
This text is included in the extents calculation and can result in major
errors in that calculation since the text is later suppressed. Resolution When processing the entities, the Block Reference for an External Reference (XREF) where the file is not found is dropped from processing. |
|
| Block conversion problem | We are still having the problem
of wrong layer during conversion: - we have a dwg file (in attachment: test_layers.dwg) with three layers("0", "ASSET" and "Room"). Two blocks (chairs) are on layer "ASSET". - we convert the dwg using: ./ax2019_L64_19_04_15 /tmp/test_layers.dwg /tmp/test_layers.svg -f=svg The final svg has: - polyline on layer "ROOM" (correct) - one block on layer "ROOM" (wrong, should be layer ASSET) - one block on layer "ASSET" (correct but both blocks should be here) if we add more blocks only one will remain on layer ASSET and all the other will be wrongly moved to layer "ROOM" |
|
| Diameter Symbol comes out in Unicode | In some circumstances, the diameter symbol (Ø) is output in PDF as Unicode (\U+2205). Interestingly, the text running vertically is correct while the text running horizontally is in Unicode. | |
| Check Directory Existence | The output directory should be
checked for existence and that it is write enabled before any other processing is done. |
|
19.05.15 |
||
| On most drawings, the drawingCoordinates matrix passed in SVG conversion contains an incorrect lowerLeft and upperRight | The incorrect calculated
lowerLeft and upperRight, makes area and distance calculations incorrect, and
also provides an incorrect transformation when passing redlines over to
DwgMerge. Attached meter_01.dwg, provides a correct drawingCoordinates matrix and svgToWorldUnits value. Using these values, DwgMerge proves to work well, areas and distances are measured correctly in CV-JS. Attached drawing P2_Hotel_L07.dwg exhibits an incorrect drawingCoordinates matrix and svgToWorldUnits value seen in many drawings. Using these values, distance and area calculation in CV-JS is incorrect, DwgMerge place objects in wrong locations. { "globalOrigin": { "x": -209650, "y" : -144301}, "units": "mm", "svgToWorldUnits": 0.00470214 } cadviewer_drawingCoordinates={ "DWG": { "lowerLeft": { "x": -237197, "y" : -71675.2}, "upperRight": { "x": 182103, "y" : 216928} }, "SVG": { "lowerLeft": { "x": 0, "y" : 1539.03}, "upperRight": { "x": 2500, "y" : 181.975} }, "Drawing Height": 1721}XXX |
|
| Frozen layer objects included in extents calculation | Frozen layer objects included in
extents calculation with drawings 3MD80188014.dwg (base) and REFGA3.dwg
(Xref). Resolution This was an OpenDesign Toolkit error that was fixed in the latest version (2019_2). |
|
| Scaling Factors Off | In some circumstances the calculated SVG scaling factors are incorrect. | |
| Add margin to PDF output | Add a blank margin around PDF drawings. This should be defined in output units, so points, or inches. So anything under 1 and larger than 0 is treated as inches and anything larger than 1 is treated as points (1/72 of an inch). | |
19.05.14 |
||
| Invisible attribute for Attributes ignored | The < Invisible > attribute on Attributes is being ignored. | |
| Empty or blank text used in Extents Calculation | Empty or blank text (both Text and MText entities) used in Extents Calculation. They should be excluded. | |
19.05.13 |
||
| Add Watermark to PDF Output | Generalized facility to add a watermark to a drawing. Add parameters for contents, height, font and location. | |
| Text Spacing is not used | When going to PDF text spacing is not preserved. | |
| Embedded bitmap is missing | An embedded bitmap is missing in
DWG->PDF conversion. The temporary
bitmap file is created, but not embedded in output PDF See attached SNCF drawing. Fails on Linux and Windows. RESOLUTION Bitmap was rotated in the DWG file. Had to rotate upon extraction and modify all height/width parameters. |
|
19.05.12 |
||
| DefaultFont Parameter is Ignored | The default font is hardcoded to Arial and the DefaultFont parameter is ignored. | |
| Program Crashes on Startup | Program Crashes on Startup | |
19.05.11 |
||
| -REPO not being followed | The Repository parameter (-repo) is supposed to ignore paths defined in XRef names and only search in directories named in the XPath parameter. This is not happening. | |
| Unicode characters not stroked out | Unicode characters beginning with \U+01 through \U+09 are not being stroked out. | |
| Unable to open directory: .\ on Linux | If an XRef is hardcoded to the path .\ it gives an "Unable to open directory: .\" message when processing XRefs on Linux. | |
19.05.10 |
||
| cvjs:tag Elements Must Use & | cvjs:tag elements must use & instead of just & | |
| Stroking Japanese Characters No Longer Works | Stroking Japanese Characters has stopped working. | |
19.05.09 |
||
| Second Fill attribute | When doing Room Layer/Text Layer processing (RL/TL) there is both a "none" and a "transparent" fill attribute. There should only be "transparent". | |
19.05.08 |
||
| Port New Toolkit to Linux | Port the latest version of the
OpenDesign toolkit (Version 2019_2) to Linux. Resolution AX2019 is ported to Linux using GCC 4.4. This version does not support PDFImport due to compiler limitations. That will be handled separately. With this version now available on both Linux and Windows, AutoXChange 19.04.XX is officially retired. |
|
| Xref w/o an extension is not found | Xref is not found if it is saved in the base drawing w/o an extension. This is only a problem on Linux. | |
| Files with embedded TIFFs will not process through -basic | The second time an embedded TIFF
is processed on Linux the conversion stops. Resolution Directly accessing the pixel data array caused a memory corruption problem. Changed back to using the slower, but obviously safer, SetPixelColor function in FreeImage. |
|
| Text Converted to Uppercase | All text in es_isocp.shx font ends up as Uppercase. | |
19.05.07 |
||
| Embedded TIFF Files Will Not Display | TIFF files that are embedded in a DWG will not display/convert. | |
| French Linetypes are Ignored | The French equivalents of the
standard line types (Dot, DotDashed, etc) are ignored. They should be mapped
to their standard equivalent like German equivalents are. RESOLUTION Added the following linetypes: TIRETPT (DASHDOT), INTERROMPU (DASH), POINTILLE (DOT), CACHE (HIDDEN), DIVISE (DIVIDE), FANTOME (PHANTOM), AXES (CENTER), BORDURE (BORDER) |
|
| Strange Message Output on Linux | The message "sh: 1: aws:
not found" is output when running on Linux. This should be eliminated.
This message is from checking the Network Address for an Amazon Web Instance when not running on an AWS server. It has no real effect but does not look good. RESOLUTION Added the parameter -network (-nw). If this parameter is not used then the check for the AWS Network Address is not made. |
|
| Line Types Not Utilized | Any linetypes beyond the standard set (Continuous, Dot, Dot-Dash, etc) are being ignored. | |
| French CONTINU Linetype Not Recognized | The French CONTINU linetype
should be treated the same as the English CONTINUOUS. RESOLUTION The test for CONTINUOUS now tests against just CONTINU which covers both names. |
|
19.05.06 |
||
| Trace and Error Messages Have Extra Semicolon | Some Trace and Error messages
have an extra semicolon in them. So the message is "a: : b" instead
of "a: b". RESOLUTION Removed extraneous semicolons. |
|
| XRef and Font names are not Case Insensitive on Linux | The actual file name must match
the case used in the AutoCAD file or it will not be found. So, if the actual
file name is filename.dwg and the XRef name stored in the DWG is FILENAME.dwg
they will not match. RESOLUTION We run all matches in findFIle through case-insensitive matching. If multiple possible files are found (FILE.dwg, file.dwg, and File.dwg are all separate file names on Linux) then no match is found and an error is output. |
|
| XRefs With No Extension Do Not Work | If the XRefs is listed as just
"filename" with no ".dwg" or ".dxf" (or
".dwt") extension then the file is not found. RESOLUTION In this case, we will add ".dwg" and see if the file is found. If not found we add ".dxf" and then ".dwt" and see if one of them is found. If so, then we go with that. If not, then the file is not found. |
|
19.05.05 |
||
| Font Files Not Found | SHX files in the Linux font
directory are not being found. Only files in the same directory as the input
file are found. Resolution In OpenDesign 4.3.2 they slightly changed the types of two parameters in the findFile method. This meant our override of findFile no longer operated as an override, so it was not being called. This actually affected DWG and XRef files too, not just font files. We changed the parameter types and shx (and other file types) files are now found as they once were. |
|
| Testing for Empty File Name | The program gives: Assertion
Failed: charIndex < getData()->nDataLength while checking for files.
The file name is empty so trying to access the first character fails (read past end of string). |
|
19.05.04 |
||
| Stroked Characters are off | When text characters are stroked
out the characters can be shifted and parts of arcs and polylines can be
missing. The definition space of small characters can be insufficient for fine precision. We multiplied the drawing definition space by 10x to allow finer control. This fixed the stroked characters, |