 | | | | | | |
| |
|
Hmmm, I'm not sure if this effort is actually making things more
compatible.
In lugnet.cad, Lars C. Hassing wrote:
> In lugnet.cad, Kevin L. Clague wrote:
> > Using MLCad as a benchmark, the name with blanks is *not* enclosed
> > in quotes. I use the remainder of the line, sans end of line as
> > the file name.
I just did a little testing myself. MLCad seems to strip off any
whitespace (tabs and space characters) at the end of the line when
it grabs the filename. Is that what you meant by "sans end of line"?
I'm not sure what happens if you actually manage to create a file
with trailing white space, something like "my file.ldr ".
> > If the new L3P allows blanks in file names, I can easily remove the
> > check. It is only in one place in the code. Once removed, the
> > rest of the code is ready for blanks in file names.
>
> I am currently going through the L3P code and I have now added support
> for filenames with spaces, both in linetype 1 and in "0 FILE xxx".
> It now uses the rest of the line as the filename.
> It also accepts filenames in double-quotes.
Well, that's ok for l3p because it doesn't create any new ldr files.
But MLCad doesn't seem to accept filenames in double quotes. (It
treats the quotes as part of the filename). So what do I do if I
want to write a program that creates new ldraw files. We now have
some programs that accept filenames in double-quotes and treat the
remainder of the line as comments. We have some programs that accept
everything but trailing whitespace as the filename. And we have some
other programs that try to do both. It's still an incompatible mess.
How about an official recommendation from ldraw.org?
FWIW, I prefer the quotes because it's less ambiguous. Consider the
possibility that you might want a meta command where the filename is
in the middle. When you don't use the quotes you don't know where the
filename ends and the meta command picks up. Kevin, I think this may
be a problem with the way you were planning on using the MLCAD group
command.
Anyhow, that's my 2 cents. Have fun,
Don
| | | | | | | | | | | | | | | |
| |
|
In lugnet.cad, Don Heyse wrote:
> Hmmm, I'm not sure if this effort is actually making things more
> compatible.
>
> In lugnet.cad, Lars C. Hassing wrote:
> > In lugnet.cad, Kevin L. Clague wrote:
> > > Using MLCad as a benchmark, the name with blanks is *not* enclosed
> > > in quotes. I use the remainder of the line, sans end of line as
> > > the file name.
>
> I just did a little testing myself. MLCad seems to strip off any
> whitespace (tabs and space characters) at the end of the line when
> it grabs the filename. Is that what you meant by "sans end of line"?
> I'm not sure what happens if you actually manage to create a file
> with trailing white space, something like "my file.ldr ".
I'll do the same.
>
> > > If the new L3P allows blanks in file names, I can easily remove the
> > > check. It is only in one place in the code. Once removed, the
> > > rest of the code is ready for blanks in file names.
> >
> > I am currently going through the L3P code and I have now added support
> > for filenames with spaces, both in linetype 1 and in "0 FILE xxx".
> > It now uses the rest of the line as the filename.
> > It also accepts filenames in double-quotes.
>
> Well, that's ok for l3p because it doesn't create any new ldr files.
> But MLCad doesn't seem to accept filenames in double quotes. (It
> treats the quotes as part of the filename). So what do I do if I
> want to write a program that creates new ldraw files. We now have
> some programs that accept filenames in double-quotes and treat the
> remainder of the line as comments. We have some programs that accept
> everything but trailing whitespace as the filename. And we have some
> other programs that try to do both. It's still an incompatible mess.
> How about an official recommendation from ldraw.org?
>
> FWIW, I prefer the quotes because it's less ambiguous. Consider the
> possibility that you might want a meta command where the filename is
> in the middle. When you don't use the quotes you don't know where the
> filename ends and the meta command picks up. Kevin, I think this may
> be a problem with the way you were planning on using the MLCAD group
> command.
Hi Don,
Nice post.
GROUP commands are defined outside the LDraw spec, but I'd guess that the
naming issues are the same. I just made a minor change to:
0 PLIST BEGIN SUB <file> // depricated
0 LPUB PLI BEGIN SUB <file>
This original version supports sub-model files within the working directory.
I now allow a variant format:
0 LPUB PLI BEGIN SUB <color> <file>
Where you can specify an alternate LDraw part (e.g. retracted pistons instead of
extended pistons.) This part requires a color. I put color first for two
reasons:
1. This is the same order specified in a type 1 text line.
2. It supports blanks in file names without the need for double quotes.
The only strike against double quotes is backward compatibility. Isn't it too
late to make this a requirement?
Kevin
>
> Anyhow, that's my 2 cents. Have fun,
>
> Don
| | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad, Kevin L. Clague wrote:
> The only strike against double quotes is backward compatibility.
Well, technically ldlite has been around since well before MLCad,
and it supports the double quotes, but MLCad is more widely used.
So I guess you could make that argument either way.
> Isn't it too late to make this a requirement?
I only asked for a recommendation, not a requirement. But I would
like some sort of decision to move forward with. Also, I suspect
that filenames with embedded spaces are not all that widely used
at this point because of the lack of any kind of standard. If you
look, you'll see everytime someone has mentioned it, the suggestion
was not to use them.
Anyhow, how about if the Ldraw Standards Committee folks have a
round of emails and give some direction. I don't really care all
that much what gets picked, just pick something so we can code it
and expect other programs to read it. Here's some choices.
1. Everything to the end of line except trailing whitespace.
2. Accept filenames with surrounding quotes (and whitespace inside).
3. Both 1 and 2 are acceptable.
4. Same as 3, but prefer 1.
5. Same as 3, but prefer 2.
6. 8.3 filenames only. Curses upon you if you do anything else.
How about it? Enjoy,
Don
| | | | | | | | | | | | | | | | | |
> > Isn't it too late to make this a requirement?
>
> I only asked for a recommendation, not a requirement. But I would
> like some sort of decision to move forward with. Also, I suspect
> that filenames with embedded spaces are not all that widely used
> at this point because of the lack of any kind of standard. If you
> look, you'll see everytime someone has mentioned it, the suggestion
> was not to use them.
I used them until I got a VERY bizarre image of the 10016 tanker in
L3p/PovRay. I promptly switched to using hyphens prefixed by the model id :)
--
Dean Earley, Dee (dean@earlsoft.co.uk)
irc: irc://irc.blitzed.org/
web: http://personal.earlsoft.co.uk
phone: +44 (0)780 8369596
| | | | | | | | | | | | | | | | | | |
In lugnet.cad, Don Heyse wrote:
>
> 1. Everything to the end of line except trailing whitespace.
> 2. Accept filenames with surrounding quotes (and whitespace inside).
> 3. Both 1 and 2 are acceptable.
> 4. Same as 3, but prefer 1.
> 5. Same as 3, but prefer 2.
> 6. 8.3 filenames only. Curses upon you if you do anything else.
>
> How about it? Enjoy,
There are other possibilities too, for example:
7. You can exceed 8.3 but don't embed spaces or other sorts of whitespace
8. Limit filenames to only the character set legal for BrickShelf folders
Not meant to be exhaustive, just to get thinking going.
| | | | | | | | | | | | | | | | | |
In lugnet.cad, Don Heyse wrote:
>
> 1. Everything to the end of line except trailing whitespace.
> 2. Accept filenames with surrounding quotes (and whitespace inside).
> 3. Both 1 and 2 are acceptable.
> 4. Same as 3, but prefer 1.
> 5. Same as 3, but prefer 2.
> 6. 8.3 filenames only. Curses upon you if you do anything else.
You could also define an escape character, to accept the character following
(including spaces) as part of the string. However, as the standard allows both /
and \ as directory separators, it would require some character other than \ (a
common choice) to be used. But as long as you use a character that is currently
invalid, it would be backward compatible.
ROSCO
| | | | | | |
