AutoCAD R12 DXF export rotates drawing by 90 degrees

[rsamurti]

When Save As AutoCAD R12 DXF is done, the whole drawing is rotated by 90 degrees.

[Alvin Penner (apenner)]

could you attach the original .svg file and the corresponding .dxf output?

[rsamurti (rsamurti)]

This is the svg file.

[rsamurti (rsamurti)]

This is the dxf file exported from svg file sent earlier.

[Alvin Penner (apenner)]

I cannot reproduce this problem. In my case I am on Windows XP, so I cannot run this conversion directly because Windows does not support the shell script ps2dxf.sh.
However, I can duplicate the process by hand: First save the .svg drawing as .ps to get the attached, which is oriented correctly.

[Alvin Penner (apenner)]

then run pstoedit from DOS to convert it to .dxf to get the attached, which is oriented correctly.

[Alvin Penner (apenner)]

I am running pstoedit version 3.45 and using the command :
pstoedit -f dxf JRC_051_Relay.ps JRC_051_my.dxf
to do the conversion. Could you try this and see if it helps?

[su_v (suv-lp)]

AutoCAD R12 DXF exported with Inkscape 0.46+devel r22547 on OS X 10.5.8

@Alvin - I don't have a DXF viewer installed to check. Does it help you
to compare it to the reporters DXF?

version info:

pstoedit: version 3.45 / DLL interface 108 (build Jul 31 2009 - release
build - g++ 4.0.1 (Apple Inc. build 5493)) : Copyright (C) 1993 - 2007
Wolfgang Glunz

[su_v (suv-lp)]

Attached is a R12 DXF file whose text objects where converted to paths with 'Path > Object to Path' before saving as DXF.

'466479-JRC_051_Relay_LeWitt-R12.dxf ' was exported to PS without converting the text to paths - the resulting DXF seems to contain control characters instead of unicode characters - could be that 'pstoedit' has similar issues with cairo Postscript output as 'psfrag' (see bug #375323)?

@Alvin - the size of your DXF file indicates that you used the export option 'Convert texts to paths' and hit bug #388257?

[Alvin Penner (apenner)]

hmm, very strange, just writing to confirm that both of the files LewittR12.dxf and LewittR12-o2p.dxf from comments 7 and 8, both have the wrong orientation. Yet when I do it by hand I get the correct orientation.
   This is a 2 step conversion, first to ps then using pstoedit to get dxf. It might be worth confirming that the ps output is oriented correctly, and then running pstoedit from a DOS prompt to see what result is produced. The pstoedit command is given in comment 6 and also in the file ps2dxf.sh.

[Alvin Penner (apenner)]

I believe the problem lies in the .ps output routine. If I generate ps output and use the option Text to Path then I get the original orientation of the drawing, if I uncheck this option then I get a landscape orientation (which in this case is actually more appropriate, because it conforms perfectly to the original aspect ratio of the page.)

[su_v (suv-lp)]

1) Inkscape 0.47pre4 with default preferences: export as Postscript PS
with default export options: 466479-JRC_051_Relay-047pre4-intermediate.ps

2) pstoedit -f dxf 466479-JRC_051_Relay-047pre4-intermediate.ps
466479-JRC_051_Relay-047pre4-intermediate.dxf

[su_v (suv-lp)]

1) Inkscape 0.47pre4 with default preferences: export as Postscript PS
with 'Convert texts to paths' export option:
466479-JRC_051_Relay-047pre4-intermediate-t2p.ps

2) pstoedit -f dxf 466479-JRC_051_Relay-047pre4-intermediate-t2p.ps
466479-JRC_051_Relay-047pre4-intermediate-t2p.dxf

[Alvin Penner (apenner)]

well, I am at a loss. I do not know what is controlling the orientation of the document. In comment 11 and 12, both dxf files are rotated 90 degrees relative to the original. It does not appear to be related to the text-to-path option. Even my own outputs are now rotated this way and I cannot get them back to normal. I assume a setting in the ps output has been altered, but it is not clear to me which setting is changed.
    The only thing that is clear is that the rotated output does a very good job on this dxf output file if the text-to-path option is used. If it is not used then you get ??? marks instead of text.

[su_v (suv-lp)]

> then you get ??? marks instead of text
As I commented in comment 8, I think this could be related to the switch to cairo output (bug #375323)

> a setting in the ps output has been altered
Could be bug #166678 “Paper size or orientation are not used when printing” or bug #437550 “Landscape PostScript output prints incorrectly”, both recently fixed in SVN for 0.47:

«The reason for this is that when generating landscape PostScript, a portrait page size needs to be used and then the drawing rotated 90 degrees counterclockwise to fit onto the portrait page. This is because portable PostScript does not contain the page size or orientation (DSC comments are ignored by printers). Creating a PostScript file where the width is greater than the height does not print correctly because the printer will render it onto a portrait page.»

[su_v (suv-lp)]

Earlier I had tried to re-import the (E)PS file back into Inkscape to check the page orientation, result: see bug #264044.

[Alvin Penner (apenner)]

    okay, so if this is a postscript issue then I will attempt to slowly bow out of the conversation as gracefully as I can under the circumstances, because my playing area is dxf, not ps.
    In purely practical terms, I think the output problem has been solved because both of the 1.4 or 1.5 MB dxf files look quite good to me, text and all, and the fact that they are rotated simply makes them fit the page better.

[Alvin Penner (apenner)]

sorry, I forgot to mention, you can easily detect whether the box is flipped or not by querying the bounding box in the ps output.

The original ps file that I posted in comment 4 had the size :

%%BoundingBox: 0 0 1375 684

The bounding box of the more recent ps files in comment 11 for example, are :

%%BoundingBox: 0 0 684 1375

which is transposed

[su_v (suv-lp)]

> both of the 1.4 or 1.5 MB dxf files look quite good to me
expect that the text is exported multiple times on top of each other... (due to other export bug)

Which version of Inkscape did you use to create 'JRC_051_Relay.ps' - older than rev 22062 resp. rev 22314?

[su_v (suv-lp)]

@rsamurti - since you are using a recent prerelease build, I see two options:

a) use the 2 step conversion with an intermediary PS file and try the pstoedit commandline options (like '-rotate x') to correct the page orientation (<http://www.helga-glunz.homepage.t-online.de/pstoedit/pstoedit.htm#section_1>).

b) (and Alvin - here you are the expert ;-) why not try to export to DXF R13?

[Alvin Penner (apenner)]

- all work done with 0.47pre4, from Oct 12.
- attached is a dxf output using R13 Desktop Cutting Plotter
- before doing the output, first Select all objects, choose the menu item Object->Ungroup and also the menu item Path->Object to Path. The reason for this is that it is necessary to remove all the transform elements from the file, because they will not be rendered correctly.
- the resulting dxf output looks reasonable, although it appears to contain some objects that were not visible in the original svg file.

[su_v (suv-lp)]

regarding the original reported bug: I tested the PS export with all 4 prerelease versions on OS X 10.5.8. The transposed BoundingBox only happens with 0.47pre4 i.e. was introduced between r22311 and r22446 (could have been the fix for bug #437550 in r22314)

LeWitt:bug suv$ grep BoundingBox 466479-JRC_051_Relay-LeWitt-047pre*.ps
466479-JRC_051_Relay-LeWitt-047pre1-default.ps:%%BoundingBox: 0 0 1375 684
466479-JRC_051_Relay-LeWitt-047pre1-default.ps:%%PageBoundingBox: 0 0 1375 684
466479-JRC_051_Relay-LeWitt-047pre2-default.ps:%%BoundingBox: 0 0 1375 684
466479-JRC_051_Relay-LeWitt-047pre2-default.ps:%%PageBoundingBox: 0 0 1375 684
466479-JRC_051_Relay-LeWitt-047pre3-default.ps:%%BoundingBox: 0 0 1375 684
466479-JRC_051_Relay-LeWitt-047pre3-default.ps:%%PageBoundingBox: 0 0 1375 684
466479-JRC_051_Relay-LeWitt-047pre4-default.ps:%%BoundingBox: 0 0 684 1375
466479-JRC_051_Relay-LeWitt-047pre4-default.ps:%%PageBoundingBox: 0 0 684 1375

[Alvin Penner (apenner)]

just writing to confirm the above, on my machine the change in orientation occurred between 0.47pre3 (Sept 28) and 0.47pre4 (Oct 12). (Windows prebuilt, don't have rev numbers)

[Adrian Johnson (ajohnson-redneon)]

It was probably bug 437550 which caused the rotation. It can be fixed by either disabling the rotation in cairo-render-context.cpp when PS surface is being used for DXF or use EPS format (which does not rotate for landscape) for the DXF conversion.

[su_v (suv-lp)]

Changing the helper extension from 'org.inkscape.print.ps.cairo' to 'org.inkscape.print.eps.cairo' in the extension definition file might be the easiest way to fix it.

Can someone with a DXF viewer test the attached dxf file - it was exported based on an intermediary EPS export with default (Inkscape) export settings.

[Alvin Penner (apenner)]

attached is a screenshot of the eps version.

[su_v (suv-lp)]

Thanks, that means the EPS as intermediary format works as fix.

The missing characters ('???') is a separate issue - I don't know if there's a workaround for it with the way cairo PS/EPS export now works (bug #375323) except staying with Inkscape 0.46 until there's either an updated version of cairo (<https://bugs.launchpad.net/inkscape/+bug/375323/comments/15>), a fix for pstoedit or a different helper application that can parse subsetted fonts in EPS/PS files or directly convert SVG > DXF.

[Alvin Penner (apenner)]

attached is an eps output from the original svg file. The orientation is compatible with the original svg and is rotated 90 degrees relative to the ps as predicted. This was done using text to paths, and using page size output.

[Adrian Johnson (ajohnson-redneon)]

I checked the DXF files from comment 7 and 24. The use of EPS in comment 24 has corrected the orientation. The character encoding is wrong but so is the DXF produced in comment 7 so that is a separate issue.

[su_v (suv-lp)]

patch to change the helper extension for 'AutoCAD DXF R12' from ps to eps in SVN trunk

[su_v (suv-lp)]

Setting to status 'In progress' - the patch that caused the rotated PS output has been reverted for the 0.47 release. There might be some changes needed once bug #437550 is finally decided.

OTOH it could be worth discussing the use of EPS as intermediate format for pstoedit (dxf) independently or looking for alternatives to pstoedit that can either handle embedded and subsetted fonts in (E)PS or parse the SVG file without intermediate format.

[su_v (suv-lp)]

> There might be some changes needed once bug #437550 is finally decided.

Closing as 'Fix Released' without milestone (the patch for bug #437550 had been reverted before the final release of 0.47, and AFAICT there seem to be no more plans to rotated the drawing/page for landscape formats in Inkscape's PS export).

Feel free to reopen if you think the report was closed in error.