[LSC] File Format Restrictions for Official Parts

[William Howard]

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

>