[LSC] LDraw File Format Specification - Comments please

[Travis Cobbs]

I just thought I'd mention it.  However, the fact that the complement
process is not unique (which I spaced on) seems reason enough to disallow it
in the spec.

--Travis

On 7/18/07, William Howard <william at howard-family.fsworld.co.uk> wrote:

>

>  I thought the main problem with using colour 24 for a sub-file is that

> the complement process is not unique.

>

> So !White = DkGrey and !LtGrey = DkGrey therefore !!White could render as

> LtGrey

>

> And it doesn't work in MLCad (which to be brutally honest, is probably a

> "better" test bed than ldraw.exe)

>

> And as this is version 1 of the spec (and not 0.27) do we have to stick

> with what works in LDraw anymore

>

> W

>

> ----- Original Message -----

> *From:* Travis Cobbs <tcobbs at gmail.com>

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

> *Sent:* Monday, July 16, 2007 9:09 PM

> *Subject:* Re: [LSC] LDraw File Format Specification - Comments please

>

> I just tested using color 24 in a type 1 line with ldraw.exe, and it

> actually worked fine (including having color 24 references in the referenced

> file invert back).  I'm not sure it's useful for anything (especially since

> the edge color is now dependent on ldconfig.ldr), but I'm not sure we

> should forbid it outright.  It obviously worked fine with ldraw.exe, and

> it's logically consistent.

>

> Note that LDView treats color 24 in a line type 1 line just like color

> 16.  (It doesn't generate a warning, either, which I need to fix.)  I'm

> pretty sure L3P does the same (although I'm pretty sure it does generate an

> error or warning).  I could easily change LDView to behave like ldraw.exe(and may well do so), but L3P can't really be made to support color 24 at

> all.

>

> --Travis

>

> On 7/16/07, William Howard < william at howard-family.fsworld.co.uk> wrote:

> >

> >  All,

> >

> > I've gone back over all the emails and tried to edit the consensus views

> > into the draft spec.

> >

> > There is one area that still needs to be discussed/agreed - that of the

> > "real world approximations"

> >

> > There are still a few areas where the reasoning needs explaining and

> > I'll try to expand these areas in the next few days.

> >

> >  If I've missed anything, mis-represented anything, or just got anything

> > plain wrong, please respond here.

> >

> > William

> >

> >  ----- Original Message -----

> > *From:* Travis Cobbs <tcobbs at gmail.com>

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

> > *Sent:* Tuesday, July 10, 2007 10:02 PM

> > *Subject:* Re: [LSC] LDraw File Format Specification - Comments please

> >

> > My comments:

> >

> > Charset encoding: technically they're probably DOS (Code Page 437) or

> > DOS/Latin (Code Page 850).  If we're going to pick one, DOS/Latin is the

> > more useful of the two.  I'm not sure if we should mention this or not.  In

> > order to be useful, software would have to do the conversion from that to

> > the current code page.  The likely current behavior (file is always assumed

> > to be in creation computer's code page) is probably more useful, although it

> > introduces problems when files are shared internationally.

> >

> > Another option would be to state that version 1.0 LDraw files are in

> > UTF-8.  That allows for full Unicode support while (mostly) maintaining

> > backwards compatibility.  (Comments with extended characters wouldn't look

> > right in software that didn't tread the LDraw file as UTF-8, but they

> > probably wouldn't break anything.)  The biggest problem with this proposal

> > would be that there would be no way for a new program to be able to tell if

> > a file was actually UTF-8, or DOS character set.  The UTF-8 to UTF-16

> > conversion routines (provided by unicode.org) would then probably fail

> > if the file contained extended DOS characters, which could be a problem.

> >

> > Quads (line type 4) should be required to be in clockwise or

> > counterclockwise order.  In my opinion, the current "recommendation" to do

> > this is insufficient.  The good/bad image in that section should be moved

> > below the text that talks about point order.  Right now it's in a confusing

> > location, since it's unclear what it's referring to.  Additionally, the text

> > flow around it looks bad.

> >

> > I believe that concave quads should be discouraged.  They could perhaps

> > be forbidden, but I definitely think they should be discouraged.

> >

> > We should perhaps have some info on overlapping polygons.  At the very

> > least mention that they will render badly in many renderers when they show

> > up in transparent parts.  Additionally, I think it should be forbidden for

> > two co-planar polygons to overlap if they are not the same color, as this

> > produces undefined results in pretty much any renderer.

> >

> > There was some disagreement in the community in my most recent thread on

> > T-junctions here:

> > http://news.lugnet.com/cad/dat/parts/?n=6086

> >

> > I think my opinion on the matter is fairly clear in that thread, and I'm

> > all for including information in the spec about the problem, along with

> > instructions that they should be avoided when practical.  However, given

> > some of the comments from part authors, I doubt we can outright forbid them

> > in the spec.

> >

> > The "series of pictures" text in the type 5 line section should simply

> > be "picture", since there's only one picture.

> >

> > --Travis

> >

> > On 7/10/07, William Howard <william at howard-family.fsworld.co.uk> wrote:

> > >

> > >  Hi gang,

> > >

> > > With all the specs that the File Format spec refers to now ratified,

> > > it's time to move onto the main event!

> > >

> > > The current file format spec is here - http://www.ldraw.org/Article45.html

> > >

> > > The current draft spec is here - http://www.ldraw.org/Article218.html

> > >

> > > I've copied the draft spec into the LSC scratch-pad area -

> > > http://www.ldraw.org/Article408.html - and made as many of the 39

> > > changes of my previous email as possible (no idea what item 9 was as it's

> > > missing from the email!).  Those I didn't feel able to change without some

> > > input from the rest of you I've embedded in red text (and surrounded with [[

> > > and ]] so you can still find them if you print out a copy)

> > >

> > > Don't know if we want to keep all comments under one thread, or start

> > > a new thread for each section of the document.

> > >

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

>

>

> _______________________________________________

> LSC mailing list

> LSC at ldraw.org

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

>

>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://five.pairlist.net/pipermail/lsc/attachments/20070718/cee2c970/attachment.html>