[LSC] File Format Restrictions for Official Parts

[William Howard]

----- 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

>