[LSC] File Format Restrictions for Official Parts

[Michael Heidemann]

Thanks, that will help me to do not waste time.

cu
mikeheide

William Howard schrieb:

> Not yet included.

>

> When I make major edits to the scratch pad, I post here, but I'll add 

> a "last edited date" to the file as well

>

> W

>

> ----- Original Message ----- From: "Michael Heidemann" <mikeheide at web.de>

> To: "LDraw Standards Committee" <lsc at ldraw.org>

> Sent: Sunday, January 20, 2008 10:20 AM

> Subject: Re: [LSC] File Format Restrictions for Official Parts

>

>

>> It would be great if you leave a comment like "last edit: yyyy-mm-dd" 

>> at the end, so everbody can see when the last change happend.

>>

>> William, do you have already included the items you found?

>>

>> cu

>> mikeheide

>>

>>

>>

>> William Howard schrieb:

>>> Ignore the last post, I posted a blank reply!

>>>

>>> OK, I've looked at

>>>  * FAQ for LDraw file types

>>>  * Patterned Part Numbers

>>>  * FAQ for LDraw Part Numbers

>>>  * L3P -check messages

>>>  * FAQ for !CATEGORY and !KEYWORDS meta-statements

>>>  * Parts Tracker FAQ

>>> which seem to be all the documents that we MAY want to incorporate 

>>> into the File Format or Restrictions for Official Parts specs - let 

>>> me know if there are any others or lugnet posts that need considering.

>>>

>>> Of these, I think most, if not all, of the first three documents 

>>> (FAQ for LDraw file types, Patterned Part Numbers, FAQ for LDraw 

>>> Part Numbers) can be incorporated into this restriction spec.

>>>

>>> Also, the relevant comments in the "L3P -check messages" document 

>>> are already incorporated into the File Format spec and the "FAQ for 

>>> !CATEGORY and !KEYWORDS meta-statements" document are in the 

>>> CATEGORY and KEYWORDS language extension; not suggesting that these 

>>> documents are deleted (the latter can't be anyway as it's the master 

>>> list of available categories), but they could be edited to remove 

>>> duplications.

>>>

>>> Lastly, the "Parts Tracker FAQ" has a few items that could be 

>>> updated (like the BFC section) but there is nothing in there that 

>>> needs moving (probably because its mainly about the PT and not file 

>>> formats)

>>>

>>> I'll try and merge these documents sometime this week.  I've added 

>>> other comments made in this thread to date.

>>>

>>> W

>>>

>>>

>>> ----- Original Message ----- From: "William Howard" 

>>> <william at howard-family.fsworld.co.uk>

>>> To: "LDraw Standards Committee" <lsc at ldraw.org>

>>> Sent: Thursday, January 03, 2008 7:29 AM

>>> Subject: Re: [LSC] File Format Restrictions for Official Parts

>>>

>>>

>>>>> If anyone wants to scan http://www.ldraw.org/library/tracker/ref/ 

>>>>> for candidate

>>>>> material you are welcome, and I'll be glad to remove it from those 

>>>>> pages.

>>>>> This was always the intention as highlighted by the first line of 

>>>>> that page.

>>>> I'll add this to my list of things to do "on the train while 

>>>> commuting to work".  If there are any other pages/posts that need 

>>>> merging, post them here (anyone) and I'll do those as well

>>>>

>>>>

>>>>> - what was the thinking around allowing "dot" within the filename in

>>>>> addition to being the extension separator? I'd not guarantee that the

>>>>> scripting behind the Parts Tracker would support that.

>>>> I suspect this is because "it propably does not matter" - if it 

>>>> does mater (and it sounds like it does), let's just remove it

>>>>

>>>>

>>>>> - since the primary target environment is Windows, there is no 

>>>>> distinction

>>>>> between upper- and lower-case letters. By convention we currently 

>>>>> issue

>>>>> parts with all upper-case names (although the filename on the 

>>>>> Name: line is

>>>>> checked to be lower-case !). Was there any special reason for 

>>>>> allowing both

>>>>> lower- and upper-case? UNIX geeks might assume that they may use 

>>>>> casing to

>>>>> provide meaning.

>>>> See comment above - I'll add a statement about part names being 

>>>> case-insensitive (but this may belong in the official spec - I'll 

>>>> double check)

>>>>

>>>>

>>>>> - It's not just Hi-Res primitives that should be coded to 4DPs. 

>>>>> All scalable

>>>>> primitives should be. The primitives reference tries to make it 

>>>>> clear which

>>>>> are not supposed to be scaled. Things like clips and technic 

>>>>> components are

>>>>> not scalable, whereas elemental primitives like discs, edges and 

>>>>> cones are

>>>>> scalable.

>>>> OK.  I took that text almost verbatim from a lugnet post, but it's 

>>>> possible I mis-read it or have since changed it.  I'll modify the 

>>>> text in this document to reflect what you have writen above.

>>>>

>>>>

>>>>> If we continue to support the "type 2 lines inside and coplanar 

>>>>> with type 4

>>>>> quads technique" for fine patterns, there will be two cases where 

>>>>> a colour

>>>>> 16 type 2 line is needed. When a subpart is reused for different 

>>>>> colour

>>>>> versions (see s/973P11A.DAT for an example) and when a pattern 

>>>>> leaves a

>>>>> narrow gap of base-part colour (see s/973P11B.DAT).

>>>> OK, I'll change this to a strong recommendatation and add notes 

>>>> about these kind of exceptions

>>>>

>>>>

>>>>> Are you saying that all comments (not just those in headers) MUST 

>>>>> be of the

>>>>> "0 // ..." form?

>>>> Yes, but only in newly submitted parts.  Existing parts should have 

>>>> "grandfather rights" to keep their existing comments.  There is a 

>>>> post (by Mike I think) somewhere in this thread about this.

>>>>

>>>>> Now (i.e. the next few days) would be the ideal time to

>>>>> apply this rule to all existing parts.

>>>> If you can make a global change in the editing/release process that 

>>>> would be good, but not strictly necessary - see above.

>>>>

>>>>> What about the trailing null comment

>>>>> line often present in parts (and probably there for a reason, once 

>>>>> upon a

>>>>> time)?

>>>>

>>>> I believe the trailing null comment, ie a single 0 on a line, was 

>>>> there to mark the end of a part when posted to lugnet etc.  

>>>> Personally I'd like to either see them all removed or the official 

>>>> spec changed to mandate that an LDraw file has a terminator line.  

>>>> However, I also think that both of these options are unreasonable - 

>>>> mainly as MLCad doesn't seem to care one way or the other and we'd 

>>>> end up "breaking" an awful lot of model files. I also seem to 

>>>> remember some discussion about an "official terminator" when we 

>>>> were discussing the library header format and the idea being 

>>>> discarded.

>>>>

>>>>

>>>>> There is a typo in the last line of this section : 

>>>>> s/confomant/conformant/.

>>>> Thanks, I'll correct it.  Doesn't surprise me there is one, what 

>>>> will surprise me is if it's the only one :-)

>>>>

>>>> William

>>>>

>>>> _______________________________________________

>>>> LSC mailing list

>>>> LSC at ldraw.org

>>>> http://five.pairlist.net/mailman/listinfo/lsc

>>>>

>>>

>>>

>>> _______________________________________________

>>> LSC mailing list

>>> LSC at ldraw.org

>>> http://five.pairlist.net/mailman/listinfo/lsc

>>>

>> _______________________________________________

>> LSC mailing list

>> LSC at ldraw.org

>> http://five.pairlist.net/mailman/listinfo/lsc

>>

>

>

> _______________________________________________

> LSC mailing list

> LSC at ldraw.org

> http://five.pairlist.net/mailman/listinfo/lsc

>