search

haplokuon / netDxf

.net dxf Reader-Writer
MIT License
994 stars 405 forks source link

Dwgcodepage with .NET Core Applications #146

Open chunky125 opened 4 years ago

chunky125 commented 4 years ago

The dwgcodepage attribute on the document is automatically completed using the field "Encoding.Default.WindowsCodePage". The behaviour has changed between .NET framework and .NET core as per https://docs.microsoft.com/en-us/dotnet/api/system.text.encoding.default?view=netframework-4.8 which means that in .NET core, it always returns unicode.

This breaks generation of .DXF files on .NET core because the codepage in the DXFDocument does not match the system one.

chunky125 commented 4 years ago

I'm going to try and create a patch for this so that the default behavior is as now (defaults to .NET default) but you can specify a particular encoding as a property of the dxfdocument.

It should be fairly simple to create the method for specifying the encoding, but I think that it will take some time to find all the text encoding calls and make sure they are using the chosen encoding.

haplokuon commented 4 years ago

Sorry, but I cannot give support to any custom builds outside what is available here at GitHub, and this includes modified source code to use the Net Standard or the Net Core libraries, and anything related with builds in Nuget provided by other users. You will have to address your issues directly to them.

StuYarrow commented 4 years ago

Might it make sense to use Encoding.ASCII to populate the code page value in the DXF header (rather than Encoding.Default), since that is what is used to create the encoding for the file itself (for DXF versions < AutoCAD2007)? This works for me (returns 1252) under both Framework 4.7.2 and Core 3.1. Hard to say more without testing under a load of different Windows locales.

For DXF versions >= AutoCAD2007, AutoCAD does not seem to care about the stated code page, but it complains if ANSI_1200 is stated and the version is < AutoCAD2007.

chunky125 commented 4 years ago

Might it make sense to use Encoding.ASCII to populate the code page value in the DXF header (rather than Encoding.Default), since that is what is used to create the encoding for the file itself (for DXF versions < AutoCAD2007)? This works for me (returns 1252) under both Framework 4.7.2 and Core 3.1. Hard to say more without testing under a load of different Windows locales.

For DXF versions >= AutoCAD2007, AutoCAD does not seem to care about the stated code page, but it complains if ANSI_1200 is stated and the version is < AutoCAD2007.

This sounds like the right approach to me, at the moment I would say that there is a bug, which is that netdxf does not consider the interaction between codepage and the DXF document version.

chunky125 commented 4 years ago

Sorry, but I cannot give support to any custom builds outside what is available here at GitHub, and this includes modified source code to use the Net Standard or the Net Core libraries, and anything related with builds in Nuget provided by other users. You will have to address your issues directly to them.

OK, I will submit to the Nuget owner as well. I did not realise that you were not the creator of the .net standard version (netDxf.netstandard by Daniel Carvajal?).

However I think that the right approach would be for .netdxf to respect the link between the DXF version and the code-page as suggested by @StuYarrow. At the moment if I create a version that the (old) etching software we use can understand, it falls over because of the code-page.

StuYarrow commented 4 years ago

Created pull request #150 for discussion.

haplokuon commented 4 years ago

Merged the request changes. In my case The Encoding.Default.WindowsCodePage and Encoding.ASCII.WindowsCodePage are the same, I cannot confirm what happens with other languages, specially those not using Latin characters like Chinese, Japanese, Korean,... In those cases I always recommend to use version 2007+ since they are saved as UTF8, and it does not required encoding and decoding text characters inside the DXF as \U+####, where #### is the for digits hexadecimal number that represent that character. It will save you some cpu cycles.

chunky125 commented 4 years ago

Thanks for the prompt fix, I have some software for laser etching which cannot use more recent files. I think in the long term we may interact directly with the etching API but for now the DXF is used to transfer the etching across.