| | | | | Is it legal to have blanks in file names in type 1 records?
I looked at
http://www.ldraw.org/modules.php?op=modload&name=News&file=article&sid=45
and it does not specify. I'd guess that LDRAW.EXE cannot handle them.
What is the LSC's position on this issue.
Kevin
| | | | | | | | | | | | | In lugnet.cad, Kevin L. Clague wrote:
> Is it legal to have blanks in file names in type 1 records?
>
> I looked at
>
> http://www.ldraw.org/modules.php?op=modload&name=News&file=article&sid=45
>
> and it does not specify. I'd guess that LDRAW.EXE cannot handle them.
>
> What is the LSC's position on this issue.
>
> Kevin
As a followup question, at first read/reread, the document is a bit confusing.
The term "line" is overloaded. In one case line means, text as it would be
viewed on a terminal, and in the other it is a graphical representation of what
mathemeticians call line segments.
As it reads we have triangle lines, quad lines, line lines, and conditional line
lines. Is it just my dyslexic mind, or is this a bit confusing to others?
Can we choose a different word for the textual representation of said things?
Maybe text records?
Kevin
| | | | | | | | | | | | | | | | | |
| |
| In lugnet.cad, Kevin L. Clague wrote:
> > I looked at
> > http://www.ldraw.org/modules.php?op=modload&name=News&file=article&sid=45
>
> As a followup question, at first read/reread, the document is a bit confusing.
> The term "line" is overloaded. In one case line means, text as it would be
> viewed on a terminal, and in the other it is a graphical representation of what
> mathemeticians call line segments.
>
> As it reads we have triangle lines, quad lines, line lines, and conditional line
> lines. Is it just my dyslexic mind, or is this a bit confusing to others?
It's not just you. Is the new version of the spec better? It still carries the
overloaded definition, but it doesn't rely on it as heavily. The new version of
the spec is at:
http://www.ldraw.org/article/218
> Can we choose a different word for the textual representation of said things?
> Maybe text records?
"Text record" just doesn't work for me.
We could call the things drawn by linetypes 2 and 5 "edges", and the things that
do stuff could be called "commands" (actually, the spec already does that).
Steve
| | | | | | | | | | | | | | | | | | | |
| |
| In lugnet.cad, Steve Bliss wrote:
> In lugnet.cad, Kevin L. Clague wrote:
> > > I looked at
> > > http://www.ldraw.org/modules.php?op=modload&name=News&file=article&sid=45
> >
> > As a followup question, at first read/reread, the document is a bit confusing.
> > The term "line" is overloaded. In one case line means, text as it would be
> > viewed on a terminal, and in the other it is a graphical representation of what
> > mathemeticians call line segments.
> >
> > As it reads we have triangle lines, quad lines, line lines, and conditional line
> > lines. Is it just my dyslexic mind, or is this a bit confusing to others?
>
> It's not just you. Is the new version of the spec better? It still carries the
> overloaded definition, but it doesn't rely on it as heavily. The new version of
> the spec is at:
>
> http://www.ldraw.org/article/218
Can we differentiate using "text lines" and "line segments"?
>
> > Can we choose a different word for the textual representation of said things?
> > Maybe text records?
>
> "Text record" just doesn't work for me.
I know. It didn't do much for me either.
>
> We could call the things drawn by linetypes 2 and 5 "edges", and the things that
> do stuff could be called "commands" (actually, the spec already does that).
See above.
>
> Steve
Kevin
| | | | | | | | | | | | | | | | In lugnet.cad, Kevin L. Clague wrote:
> Is it legal to have blanks in file names in type 1 records?
No. LDraw commands are space-delimited, so a filename containing blanks would
result in a 'Part' command with invalid formatting/syntax. That is, it would
have too many parameters.
> I looked at
>
> http://www.ldraw.org/modules.php?op=modload&name=News&file=article&sid=45
>
> and it does not specify.
Hmm. It should be more explicit on this point. It should probably have a whole
section on naming LDraw files.
> I'd guess that LDRAW.EXE cannot handle them.
Definitely not. LDRAW.EXE can only handle 8.3 file names and directories.
> What is the LSC's position on this issue.
<insert image from Bloom County, with three "commentators" (Opus, Portnoy and
Hodge Podge) taking positions>
Apparently, we don't have one. ;) I'll work up something and post it.
Steve
| | | | | | | | | | | | | | | | | | | In lugnet.cad, Steve Bliss wrote:
> In lugnet.cad, Kevin L. Clague wrote:
> > Is it legal to have blanks in file names in type 1 records?
<snip>
> > What is the LSC's position on this issue.
>
> <insert image from Bloom County, with three "commentators" (Opus, Portnoy and
> Hodge Podge) taking positions>
>
> Apparently, we don't have one. ;) I'll work up something and post it.
Thanks Steve!
>
> Steve
Kevin
| | | | | | | | | | | | | | | | | | | |
| |
|
How about this for a File Naming section to be added to the file spec?
(the following text is formatted for FTX display; it will be reformatted for
HTML display when it is added to the LDraw.org File Format document)
File Names in LDraw
The LDraw language was originally developed for use with DOS 8.3 file names.
This is generally the most restrictive file naming standard, so continuing to
follow it will result in the greatest portability across computer platforms.
However, most LDraw tools allow greater flexibility in naming model files.
In general, the following restrictions apply to LDraw files:
- No space characters allowed in file names. This restriction is required for any file that will be referenced by another LDraw file. The LDraw language does not support space characters embedded in file names.
- No space characters in directory names. This varies between tools, but is generally a good rule to follow.
- File names should be considered case-insensitive.
- Backslash (\) is used as the delimiter in path names.
- Long file names are generally allowed.
- Files in the LDraw.org Modeling Library must follow the DOS 8.3 naming standard, along with a number of other restrictions. See the FAQ for Part Numbers, in the PT Reference pages.
- Standard model files should use the LDR extension. LDR is for LDraw file.
- Files in the LDraw.org Modeling Library use DAT extension. DAT is a generic file extension (standing for Data), and is been used for LDraw files since the beginning of LDraw-history.
- Compound files use an extension of MPD, for Multi-Part DAT. See the MPD Language Extension.
| | | | | | | | | | | | | | | | | | | | | In lugnet.cad, Steve Bliss wrote:
|
How about this for a File Naming section to be added to the file spec?
(the following text is formatted for FTX display; it will be reformatted for
HTML display when it is added to the LDraw.org File Format document)
File Names in LDraw
The LDraw language was originally developed for use with DOS 8.3 file names.
This is generally the most restrictive file naming standard, so continuing to
follow it will result in the greatest portability across computer platforms.
However, most LDraw tools allow greater flexibility in naming model files.
In general, the following restrictions apply to LDraw files:
- No space characters allowed in file names. This restriction is required for any file that will be referenced by another LDraw file. The LDraw language does not support space characters embedded in file names.
- No space characters in directory names. This varies between tools, but is generally a good rule to follow.
- File names should be considered case-insensitive.
- Backslash (\) is used as the delimiter in path names.
- Long file names are generally allowed.
- Files in the LDraw.org Modeling Library must follow the DOS 8.3 naming standard, along with a number of other restrictions. See the FAQ for Part Numbers, in the PT Reference pages.
- Standard model files should use the LDR extension. LDR is for LDraw file.
- Files in the LDraw.org Modeling Library use DAT extension. DAT is a generic file extension (standing for Data), and is been used for LDraw files since the beginning of LDraw-history.
- Compound files use an extension of MPD, for Multi-Part DAT. See the MPD Language Extension.
|
I like it Steve. Thanks much.
Ive gotten problem reports over the last week or so that brought this to light
for me. MLCad allows blanks in file names, and LPub percieves them as separate
tokens in a type 1 text line, and ignores the extra tokens.
MLCad also doesnt encourage the user to put the top-level model as the first
file in an MPD. I get LPub bug reports about this one every couple of months.
Thanks for the quick reply!
Kevin
| | | | | | | | | | | | | | | | | | | | | | In lugnet.cad, Steve Bliss wrote:
|
How about this for a File Naming section to be added to the file spec?
|
See below. Ive rearranged the order of the bullets to fit my comments.
|
(the following text is formatted for FTX display; it will be reformatted for
HTML display when it is added to the LDraw.org File Format document)
File Names in LDraw
The LDraw language was originally developed for use with DOS 8.3 file names.
This is generally the most restrictive file naming standard, so continuing to
follow it will result in the greatest portability across computer platforms.
However, most LDraw tools allow greater flexibility in naming model files.
In general, the following restrictions apply to LDraw files:
- No space characters allowed in file names. This restriction is required for any file that will be referenced by another LDraw file. The LDraw language does not support space characters embedded in file names.
|
Change to no whitespace characters, this way we exclude tabs, etc.
|
- Long file names are generally allowed.
|
How about:
Long file names are allowed. File names may be restricted to 8.3 format at the
program developers option.
|
- File names should be considered case-insensitive.
- Backslash (\) is used as the delimiter in path names.
|
These are good.
|
- No space characters in directory names. This varies between tools, but is generally a good rule to follow.
- Files in the LDraw.org Modeling Library must follow the DOS 8.3 naming standard, along with a number of other restrictions. See the FAQ for Part Numbers, in the PT Reference pages.
|
Im not sure these belong in the file spec. Maybe in a file name FAQ or the
Official Library standards document (which Ive been working on spratically)?
|
- Standard model files should use the LDR extension. LDR is for LDraw file.
- Files in the LDraw.org Modeling Library use DAT extension. DAT is a generic file extension (standing for Data), and is been used for LDraw files since the beginning of LDraw-history.
- Compound files use an extension of MPD, for Multi-Part DAT. See the MPD Language Extension.
|
This is already in the proposed spec (1.0.0) in a more general form.
Speaking of the 1.0.0, Ive been trying to move forward with ratifing it as the
new official spec for 2 years now. Maybe now is the time to do so?
-Orion
| | | | | | | | | | | | | | | | | | | | | | | | In lugnet.cad, Orion Pobursky wrote:
snip
|
This is already in the proposed spec (1.0.0) in a more general form.
Speaking of the 1.0.0, Ive been trying to move forward with ratifing it as
the new official spec for 2 years now. Maybe now is the time to do so?
|
Is there anything that I can do to help get this ratified?
Kevin
| | | | | | | | | | | | | | | | | | | | | | In lugnet.cad, Steve Bliss wrote:
|
- Backslash (\) is used as the delimiter in path names.
|
You might want to take a look at 2593.dat (including the author ;-). (In your
defense, thats a really old file.)
Having said that, most places in the parts library, backslash (\) is used as
the delimiter in path names. However, there are some parts (2593.dat included)
that use forward slash (/). DOS and Windows dont care. Other operating
systems have to convert all the backslashes to forward slashes (an extremely
minor thing, especially when compared to supporting the case-insensitive
clause).
I would suggest either explicitly stating that both are allowed, or thinking
about updating those parts in the parts library that use forward slash.
--Travis Cobbs
| | | | | | | | | | | | | | | | | | | | In lugnet.cad, Travis Cobbs wrote:
|
In lugnet.cad, Steve Bliss wrote:
|
- Backslash (\) is used as the delimiter in path names.
|
You might want to take a look at 2593.dat (including the author ;-). (In
your defense, thats a really old file.)
|
Yah, I think that was the first official part with sub-part files.
|
Having said that, most places in the parts library, backslash (\) is used as
the delimiter in path names. However, there are some parts (2593.dat
included) that use forward slash (/). DOS and Windows dont care. Other
operating systems have to convert all the backslashes to forward slashes (an
extremely minor thing, especially when compared to supporting the
case-insensitive clause).
I would suggest either explicitly stating that both are allowed, or thinking
about updating those parts in the parts library that use forward slash.
|
Id lean toward updating the files with s/ references to s\. The PT is
definitely coded toward using only backslashes.
Steve
| | | | | | | | | | | | | | | |
| |
| In lugnet.cad, Kevin L. Clague wrote:
> Is it legal to have blanks in file names in type 1 records?
>
> I looked at
>
> http://www.ldraw.org/modules.php?op=modload&name=News&file=article&sid=45
>
> and it does not specify. I'd guess that LDRAW.EXE cannot handle them.
>
> What is the LSC's position on this issue.
(Note FUT lugnet.cad.dev)
I realize that spaces are officially a no-no, but since I've also seen files
that contain references to sub-models with spaces in the filenames, I'm adding
support for this to the next LDView release. It will generate a warning, but it
will load the file (as long as there aren't any trailing or leading spaces in
the filename; I won't be supporting that).
I understand why it's not officially supported by the spec, but the reason I'm
adding support for it is because it's not really fair to users to not allow
spaces in their filenames. I don't think it should be necessary for users to
know anything about the internals of the file format that their files are
created with. And the fact is that it's pretty easy to support spaces in
filenames.
The only reason I'm not supporting leading or trailing whitespace is that I
suspect this will cause some existing files to fail to load, since it was never
a problem before to have multiple spaces before the filename, or trailing
whitespace after the filename.
--Travis Cobbs
| | | | | | | | | | | | | | | | |
| |
| In lugnet.cad, Travis Cobbs wrote:
> In lugnet.cad, Kevin L. Clague wrote:
> > Is it legal to have blanks in file names in type 1 records?
> >
> > I looked at
> >
> > http://www.ldraw.org/modules.php?op=modload&name=News&file=article&sid=45
> >
> > and it does not specify. I'd guess that LDRAW.EXE cannot handle them.
> >
> > What is the LSC's position on this issue.
>
> (Note FUT lugnet.cad.dev)
>
> I realize that spaces are officially a no-no, but since I've also seen files
> that contain references to sub-models with spaces in the filenames, I'm adding
> support for this to the next LDView release. It will generate a warning, but it
> will load the file (as long as there aren't any trailing or leading spaces in
> the filename; I won't be supporting that).
>
> I understand why it's not officially supported by the spec, but the reason I'm
> adding support for it is because it's not really fair to users to not allow
> spaces in their filenames. I don't think it should be necessary for users to
> know anything about the internals of the file format that their files are
> created with. And the fact is that it's pretty easy to support spaces in
> filenames.
>
> The only reason I'm not supporting leading or trailing whitespace is that I
> suspect this will cause some existing files to fail to load, since it was never
> a problem before to have multiple spaces before the filename, or trailing
> whitespace after the filename.
Travis,
I have done the same in LPub. Easier to implement it than explain it every
time someone gets burned.
Kevin
>
> --Travis Cobbs
| | | | | | |