LDraw.org Discussion Forums

Full Version: Leading or trailing white space characters in file names
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2 3 4 5 6
Out of curiosity, I did a search in the parts library on my computer using the following regex:
Code:
^[ \t]+[0-5]
(The regex matches <beginning of line><one or more spaces or tabs><number between 0 and 5>.)

It resulted in 113,134 matching lines in 1217 files. For comparison's sake, removing the leading white space from the regex resulted in 1,093,769 matching lines in 6553 files, which means that over 10% of the lines in LDraw files have leading white space.

So I think we should formalize that white space is allowed before the line type.

On a somewhat related, but separate note, I think that we should disallow white space before the 0 on the first line of an LDraw file, because the "0 " at the beginning of the file can be used as something of a magic number for the LDraw file type.
Chris Dee Wrote:Leading whitespace on line types 1 to 5 is very common in the official library, as these were introduced by the inlining function of at least one older authoring tool. In the past, I believe script that makes "~Moved to" files also put a leading space before the Type 1 line.

Fortunate then that the lines I would reject are all file structure metas like 0 FILE, 0 STEP, etc.

I guess I have to fix my parser!

Allen
Travis Cobbs Wrote:On a somewhat related, but separate note, I think that we should disallow white space before the 0 on the first line of an LDraw file, because the "0 " at the beginning of the file can be used as something of a magic number for the LDraw file type.

I'm not sure I completely understand what you mean here, but isn't this a 'header issue' instead of a 'file format' issue?
Many file types have a "magic number" at the beginning so programs can determine whether or not a file is of a given type without having to rely on the file's extension. For example, the first four characters of a GIF file are GIF8 (followed by either 7 or 9a, depending on the GIF version). Given LDraw's original generic .dat extension, having a magic number at the beginning of LDraw files could be useful. And since the first line is supposed to be a comment with the file's description (and is required to be that for parts), disallowing white space before the 0 would give something of a magic number (although not a very unique one). It's not perfect, but I think it's better than nothing.
Ah, ok.

I thought you mend like is a part or model Smile

In this light I would agree on advising the removal of leading white space for the first line. But I don't think it should be part of the format, only a recommendation in order to keep the format simple.
I agree that there should be no leading space on type 0 lines.
I'm OK with this, but I will point out that the current official library contains 11 parts and 2 primitives that contain a total of 31 type 0 lines with leading white space. Since the list is relatively small, I'm including it here:

Code:
C:\LDRAW\p\48\3-16edge.dat(20): 0
  C:\LDRAW\p\48\3-16ndis.dat(22): 0
  C:\LDRAW\parts\2435.dat(825): 0 BFC INVERTNEXT
  C:\LDRAW\parts\2920.dat(104): 0 BFC INVERTNEXT
  C:\LDRAW\parts\2920.dat(106): 0 BFC INVERTNEXT
  C:\LDRAW\parts\2920.dat(117): 0 BFC INVERTNEXT
  C:\LDRAW\parts\2920.dat(124): 0 BFC INVERTNEXT
  C:\LDRAW\parts\2920.dat(126): 0 BFC INVERTNEXT
  C:\LDRAW\parts\30235.dat(17): 0 1 16 0 32 0 40 0 0 0 -20 0 0 0 16 box5.dat
  C:\LDRAW\parts\30235.dat(436): 0
  C:\LDRAW\parts\30382.dat(17): 0 TEXTURE END
  C:\LDRAW\parts\4022.dat(320): 0 BFC INVERTNEXT
  C:\LDRAW\parts\4022.dat(371): 0 BFC INVERTNEXT
  C:\LDRAW\parts\4022.dat(409): 0 BFC INVERTNEXT
  C:\LDRAW\parts\4035.dat(16): 0 BFC INVERTNEXT
  C:\LDRAW\parts\4035.dat(56): 0 BFC INVERTNEXT
  C:\LDRAW\parts\4035.dat(65): 0 BFC INVERTNEXT
  C:\LDRAW\parts\4035.dat(68): 0 BFC INVERTNEXT
  C:\LDRAW\parts\4035.dat(71): 0 BFC INVERTNEXT
  C:\LDRAW\parts\4035.dat(74): 0 BFC INVERTNEXT
  C:\LDRAW\parts\4215ap66.dat(14): 0 Red Cross Pattern
  C:\LDRAW\parts\4215ap66.dat(19): 0 Background
  C:\LDRAW\parts\6199.dat(42): 0 Tile  2 x  6
  C:\LDRAW\parts\6199.dat(43): 0 Created by SimLego v 0.31
  C:\LDRAW\parts\7930.dat(22): 0 BFC INVERTNEXT
  C:\LDRAW\parts\7930.dat(26): 0 BFC INVERTNEXT
  C:\LDRAW\parts\7930.dat(28): 0 BFC INVERTNEXT
  C:\LDRAW\parts\7930.dat(30): 0 BFC INVERTNEXT
  C:\LDRAW\parts\7930.dat(32): 0 BFC INVERTNEXT
  C:\LDRAW\parts\973p8a.dat(15): 0 COMMENT neck mark
  C:\LDRAW\parts\s\3739a.dat(300): 0 2 24 29.54 0 5.21  28.19 0 10.26
In principle I'm against restricting anything without a good reason. So my question: why allow leading white space on 1..5 and not on 0 ?

Except for the file type issue Travis raised (which only affects the first line), I don't see any good reason for issuing this restriction.

Inlining can be a very powerful tool when working with (very) large ldr files. So why suddenly disallowing inlining 0 lines, which basically invalidates all files using inlined coded for readability purposes.

Just imagine writing e.g. a c++ program where it (only) isn't allowed to inline the 'for' statement.

For example:

Code:
0 my file
1 ..
1 ..

0 start of some sub construction (e.g. building book 1/2)
1 ..
1 ..
0 don't forget this next part is a tmp stand in
1 ..

  0 start of some sub sub construction (e.g. generated flex tube)
  1 ..
  1 ..
  0 end of sub sub

1 ..
1 ..
0 end of sub

I know you could use mpd's and or subfiles but, sometimes you just need every thing in a single file that also needs to remain readable.

And besides working with a huge mpd can be simplified inlineing the submodels per '0 FILE' statement, this would also shift the headers of those subfiles which would make the whole mpd invalid using the proposed restriction.

So imho such a restriction doesn't add anything to the spec (and the users), it only takes something away.

edit: Spell check was disabled in my browser for some reason.
Yes, you are right. Let's just apply it to the first (part description) line.
I agree with Roland as well. Whitespace everywhere! (Recanting my earlier belief that leading whitespace is wrong.)

Allen
Pages: 1 2 3 4 5 6