Closed michal-josef-spacek closed 6 months ago
The first issue is the encoding of DIMLWD. Originally -2, from wine JSON to DWG conversion -1
It's FIELD_BSd() macro.
In log:
right:
DIMLWD: 4294967294 [BSd]
bad:
DIMLWD: 2147483647 [BSd]
The second problem: wine version adds extra APPID table
Next object: 89 Handleoff: 0x1 [UMC] Offset: 24 [MC] @32967
==========================================
Object number: 89/59, Size: 25 [MS], Type: 67 [BS], Address: 32969
Add table record APPID [89] Decode table record APPID
bitsize: 164 [RL] @3.2
Hdlsize: 0x24, hdl_dat: @20.4 - @25.0 (25)
handle: 0.2.12D [H 5]
EED[0] size: 0 (end)
num_eed: 0
num_reactors: 0 [BL 0]
ownerhandle: (4.1.9) abs:9 [H 330]
xdicobjhandle: (3.0.0) abs:0 [H 360]
--common_size: 60
name: "LibreDWG" [T 2]
is_xref_ref: 1 [B 0]
is_xref_resolved: 0 [BS 0]
is_xref_dep: 0 [B 0]
xref: (5.0.0) abs:0 [H 0]
unknown: 0x0 [RC 71]
padding: +4
object_map{12D} = 89
padding: 0/0 (4 bits)
crc: F3C1 [RSx]
check_CRC 32967-32994 = 27: F3C1 == F3C1
The third issue: Different Second Header junk_r14 value: Right:
junk_r14: 0x3615F9E5B5CE9B52 [RLL 0]
Bad:
junk_r14: 0x7FFFFFFF [RLL 0]
The fourth issue:
Different display_brightness_bl
in VISUALSTYLE object:
Right:
display_brightness_bl: -50 [BLd 44]
Bad:
display_brightness_bl: 2147483647 [BLd 44]
I see but they both still incur in the "Recovery Mode" issue? Right?
I see but they both still incur in the "Recovery Mode" issue? Right?
yes
My feeling is that you are so close to resolve the "Recovery Mode" issue but maybe I'm wrong. I also offered a donation many times if it could help.
The first and fourth issue is related to two things: 1) Bad conversion from DWG to JSON (-2 → 4294967294) 2) long in in_json.c on Windows is 32bit, so 4294967294 is not possible in this type.
@rurban What about 2) ? I created https://github.com/michal-josef-spacek/libredwg/commit/47c43c20c1f5519bb34b63eccfcbc11d6bc2b84c for fix.
I think that is better to not use long type when is different on systems.
The second problem: wine version adds extra APPID table
Not a problem, but on purpose for unhandled classes roundtrips
The first and fourth issue is related to two things:
1. Bad conversion from DWG to JSON (-2 → 4294967294) 2. long in in_json.c on Windows is 32bit, so 4294967294 is not possible in this type.
this must be uint32_t, not long. 4294967294 is MAX_UINT32 - 1
@rurban What about 2) ? I created michal-josef-spacek@47c43c2 for fix.
I think that is better to not use long type when is different on systems.
Sure, but we need strtol() which returns long, even on windows. But since we only need 32bit, it is ok
Should be fixed now
Should be fixed now
Thank you very much. I am going to test.
The second problem: wine version adds extra APPID table
Not a problem, but on purpose for unhandled classes roundtrips
I don't understand. On Linux not present, with mingw/wine present. :-)
The second problem: wine version adds extra APPID table
Not a problem, but on purpose for unhandled classes roundtrips
I don't understand. On Linux not present, with mingw/wine present. :-)
ok, I see :-D
if (fixup)
{
...
new_appid = add_LibreDWG_APPID (dwg);
...
}
I am closing this ticket.
Tested on last git branch on Linux and Windows with ./configure --disable-bindings --enable-write --enable-trace -- enable-debug
and working.
There are issues in compilation without --enable-debug
, see follow up: https://github.com/LibreDWG/libredwg/issues/954
The conversion from JSON to DWG is not same on Windows as on Linux.
Examples on libredwg.0.13.3: linux.tar.gz wine.tar.gz
Diff between dwgread output of Windows dwgrewrite and conversion versions: