You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The "Int" fields don't have a specified encoding. I assume they are unsigned numbers starting from 0 and in big or little endian format when they are bigger than a single byte.
"String" fields don't have a specified encoding. UTF-8? Its inefficient for CJK text though. It would perhaps be better to add a field that says the encoding for all text fields (except the URL, it should perhaps always be in ascii?). UTF-8 and UTF-16 would be enough I think.
The "Color Hex" field doesn't have a specified colour space. SGRB, Adobe RGB (1998) or something else? The field would also better be described as three separate bytes to reduce confusion about what each byte means.
Date and Time lacks time zone info. Perhaps always use UTC? They would also be better described as separate fields for each component. It would take just as many bytes to use 2 bytes for year, one for month and one for day, but no special code would be needed to make use of the fields. Same with time. 3 bytes with HH in one byte, MM in another and SS in the third. That would be harder to implement incorrectly and nothing is gained from using multiply and add to join them into a single number. When converting the number to text one most often want to handle them component by component anyway.
Many filaments today have printed info about bed and print temperatures given in ranges. I've never seen any such temp ending in anything but 0 or 5. So perhaps instead of using two fields with two bytes, use four fields (min/max print/bed), each with a single byte given in 5⁰C values. That would give a maximum temperature of 1275⁰C, which should be enough.
The text was updated successfully, but these errors were encountered:
The "Int" fields don't have a specified encoding. I assume they are unsigned numbers starting from 0 and in big or little endian format when they are bigger than a single byte.
"String" fields don't have a specified encoding. UTF-8? Its inefficient for CJK text though. It would perhaps be better to add a field that says the encoding for all text fields (except the URL, it should perhaps always be in ascii?). UTF-8 and UTF-16 would be enough I think.
The "Color Hex" field doesn't have a specified colour space. SGRB, Adobe RGB (1998) or something else? The field would also better be described as three separate bytes to reduce confusion about what each byte means.
Date and Time lacks time zone info. Perhaps always use UTC? They would also be better described as separate fields for each component. It would take just as many bytes to use 2 bytes for year, one for month and one for day, but no special code would be needed to make use of the fields. Same with time. 3 bytes with HH in one byte, MM in another and SS in the third. That would be harder to implement incorrectly and nothing is gained from using multiply and add to join them into a single number. When converting the number to text one most often want to handle them component by component anyway.
Many filaments today have printed info about bed and print temperatures given in ranges. I've never seen any such temp ending in anything but 0 or 5. So perhaps instead of using two fields with two bytes, use four fields (min/max print/bed), each with a single byte given in 5⁰C values. That would give a maximum temperature of 1275⁰C, which should be enough.
The text was updated successfully, but these errors were encountered: