mozman / ezdxf

Python interface to DXF
https://ezdxf.mozman.at
MIT License
912 stars 191 forks source link

.stb file won't parse #1069

Closed rchive1 closed 5 months ago

rchive1 commented 5 months ago

This isn't a bug, exactly. I'm just trying to understand what's happening:

I'm trying to acadctb.load() a STB file. I get a ValueError: could not convert string to float: '0.0076200000000 (+7.Z+"8V?S_LC )' After the contents of the file get uncompressed, here is the portion at the end of the file that it can't parse:

custom_lineweight_table{
 0=0.0076200000000 (+7.Z+"8V?S_LC )
 1=0.0254
 2=0.0762
 3=0.1
 4=0.127
 5=0.15
 6=0.17780000000 (44F=@";"QC\\SM0)
 7=0.2
 22=1.2
 8=0.254
 23=1.4
 9=0.3
 10=0.35560000000 (44F=@";"UC_SN )
 11=0.4
 12=0.4318
 13=0.5
 14=0.508
 15=0.6
 16=0.635
 17=0.7
 18=0.8
 19=0.9
 20=1.0
 21=1.06
 24=1.58
 25=2.0
 26=2.11
}

Do you know what the (+7.Z+"8V?S_LC ) portion could mean?

Thanks.

mozman commented 5 months ago

No, I have no idea. There exist no documentation for stb and ctb files.

rchive1 commented 5 months ago

I was afraid of that.

Here's another portion of a .pc3 file with similar additional info between parenthesis:

media{
 selection_method=2
 type="
 dm_orientation=1
 actual_printable_bounds_llx=5.7937498093 (    P,PL%T 8_0)
 actual_printable_bounds_lly=17.793750763 (    0#/+,4"%9@)
 actual_printable_bounds_urx=273.60623169 (    (+,9<4"T7@)
 actual_printable_bounds_ury=198.10624695 (    8&;#:$ <30)
 number_of_copies=1
 size{
  name="ANSI_A_(11.00_x_8.50_Inches)
  group=0
  landscape_mode=TRUE
  longplot_reduction=1.0
  media_description{
   printable_bounds_llx=5.7937498093 (    P,PL%T 8_0)
   printable_bounds_lly=17.793750763 (    0#/+,4"%9@)
   printable_bounds_urx=273.60623169 (    (+,9<4"T7@)
   printable_bounds_ury=198.10624695 (    8&;#:$ <30)
   printable_area=48289.9375
   dimensional=TRUE
   media_bounds{
    urx=279.39999390 (    8&9V<4!J5P)
    ury=215.89999390 (    P,S\\:D"QW0)
   }
  }
 }
}

I wonder if the parser should put that extra text between parenthesis into another spot in the data dictionary so it doesn't get lost but will still parse.

Anyway, thanks for the info!

mozman commented 5 months ago

I don't see any reason to preserve this unknown data, but I added a sanitizer function to ignore this unknown appendix.

mozman commented 5 months ago

@rchive1 if this issue is solved for you, please close it

rchive1 commented 5 months ago

Sorry, I'm new-ish to GitHub, still.

Thank you.