[LSC] File Format Restrictions for Official Parts

[William Howard]

> 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