let's drop the 64 chars part title limit, please

[Steffen]

I'd like to ask if we could drop the 64 chars par title limit, please.

Which ancient software relies on that?

The current force of this limit leads to the effect that important keywords
of the title must be abbreviated, so they cannot be grepped properly anymore,
or left out completely.

All modern software should be able to treat a first line in the file of arbitrary length, IMHO.

I'd like to ask the LSC for a drop of this limit, please.

[Daniel Goerner]

I agree.

When you got a description like:

0 Windscreen 8 x 6 x 3 Curved Top Angled Canopy

there's not much left to add infos about the pattern.

[Willy Tschager]

I'm fine with the limit. Not 'cos of backwards compatibility, but human readability. A:

"Minifig Helmet with Hexagonal Top, Hoses, Silver Alien Pattern" - 62 characters

gets you a good picture what this part is about. I cannot see any benefit in:

"Minifig Castle Helmet with Hexagonal Top with Hoses, Buttons, lots of Yellow Stripes on Green Background and Silver Alien Pattern" - 129 characters

w.

[Steffen]

You are describing the opposite extreme, using overly long titles.
There is something in the middle.

I am also aiming at the human readability. Here are examples from official parts
where the enforcement of 64 characters spoils that:

(a) unwanted abbreviations:
"Animal Dragon Oriental w. Chr.Gold Head and Tr.Red Wings (Comp.)"
should be
"Animal Dragon Oriental with ChromeGold Head and TransRed Wings"
, because (a) the "(Complete)" suffix is superfluous anyway,
and people searching for "TransRed" currently will not find this part,
as well as people searching for "ChromeGold".
Another example:
"Technic Brick 2 x 2 w/ Hole, Click Rot. Hinge (H) and Socket"
will not be found by people searching for
"Click Rotation Hinge".

(b) unsystematic spaces
Currently official are "Electric_9V Battery Box ..." parts and "Electric__9V Battery Box ..." parts.
I have illustrated the 1 and 2 spaces here with underscores.
The 1 space variant does so to squeeze its title into the 64 chars limit.
This way, it does not get sorted properly anymore by mklist.


So you probably get the picture. I am not asking to allow ridiculous long stories
as titles. I just want to be able to spell out all relevant title words as needed,
so they can be found.
And I want proper sorting. I find the rule "use double spaces in front of single digit numbers _sometimes_" in the title
a little old-fashioned, but when you have cast a view into file parts.lst, sorted by description, you begin to like it.
That sorting is spoilt by arbitrarily leaving away the spacing due to the 64 chars limit.

I think the PT admin will automatically keep an eye on ridiculously long titles on the PT.

And since there's no technical limit anymore (I think LDEDIT had problems, but not nowadays software),
in my opinion we should _drop_ the limit.

[Daniel Goerner]

Again (this was before the Partname was changed):

Windscreen 8 x 6 x 3 Curved Top Angled Canopy (48 characters)

add the words "with" and "Pattern" and you have 61 characters. I now had 3 characters (make it 2, because of a space) left to tell what pattern it was. "Millennium Falcon" has a few characters more than 2. "MF" could be easily misunderstood.

Of course, you shouldn't excessivly describe every detail of your part, but you should be able to describe it at all.

[Tim Gould]

I can't remember what part it was, but I hit the 64 character limit recently too. It's frustrating to try to work out some silly acronym when hole words would be fine.

Tim

[Chris Dee]

Does somebody have the time to make an artificial 100-character wide (?) parts.lst and do an impact analysis on current LDraw toolset?

[Steffen]

I'd like to volunteer for the list.
I'll take the existing official 2012-01 parts.lst and extend the names so the strange abbreviations are gone,
and the spacing is correct.
This will take me some time. I will come back here when finished.

BTW: this should not stop anyone else from doing the same, if wanted, of course.
We can post both results here and compare.

[Steffen]

yes, same here. especially because noone ever later will search for the acronym again. it's just sitting there, useless.
that's the reason for this initiative.

[Chris Dee]

I don't think you need to do the entire list just to test the impact - just a few challenging examples will do. This might help to discover how long the title needs to be.

[Tim Gould]

I've just written my own version of mklist that can replace overly long lines by unique (with a caveat unlikely to be needed) short-hand identifiers. So if I can get it compiled on windows and tested properly we don't need to worry as users can simply demand that their Parts.lst file is restricted to 64 characters.

Will attach code elsewhere for anyone in possession of a C++ compiler.

[Willy Tschager]

Though now we have a new Parts.lst generator prog the question hasn't been answered yet and it is still not clear if we are going to drop the limit or not.

w.

[Steffen]

This is because we still need to investigate whether the existing major software has a problem with that drop.
If not, I suggest that we drop that restriction.
Note that I'm not advocating ridicilously long part titles,
but I want to get rid of the unnecessary abbreviations in some titles which anyway nobody will search for.

[Steffen]

yikes, I still have to do this test on my TODO list ... :-(

intuitively I don't really expect problems. times of "80 characters wide DOS displays" are long gone (fortunately)

[Steffen]

just to bring our attention back to this.

on the PT we're currently struggling again with this unlucky limit :-(
http://www.ldraw.org/cgi-bin/ptdetail.cg...cpb471.dat
http://www.ldraw.org/cgi-bin/ptdetail.cg...bpb471.dat

[Michael Heidemann]

I think all are waiting for your result of testing!

That has to be done before anything else!

[Michael Heidemann]

What ristrictions do we have currently for the PT ?

Is it a big deal for that to change?

[Michael Heidemann]

I did a very quick check for LDView and MLCad (only file load).
Both did not run into errors.

DATHeader has of course the 64 characters build in to check against that, but the code is already changed to have a quick change to another limit.

[Alex Taylor]

Just adding my 2cents...

I'm strongly in favour of dropping the 64-chars limit, but I would not be happy to see the limit simply increased to another arbitrary value. IMO it should simply be removed completely.

[Travis Cobbs]

IIRC, MLCAD can't properly scan for parts when any parts have a title that is longer than 64 characters. Additionally, it can't handle titles that are too long in parts.lst. I think Tim Gould had a workaround for that, which was to somehow truncate the long names while generating parts.lst with his own replacement for mklist.

Assuming that the parts.lst that goes into official releases is generated with the truncated names, and assuming that the mklist replacement is generally available, I don't have any problems with removing the restriction.

[Tim Gould]

Just to let everyone know, I very much doubt I'll have time to further work on and test my replacement code for many months.

That said, on the testing I did do it seemed to work fine. But if anyone else wants to try breaking it that would be great. And it's pretty straightforward C++ so I doubt any of the far better coders round here would have trouble fixing it.

I'll update the thread with latest version later today.

Tim

[Max Martin Richter]

Hej,
just for clarification. I want to know whats about the 64 character limit.
I can read in http://www.ldraw.org/article/218#name
Sorry, I confused name and part description, so I edited out the wrong content here.
but of course, it's not possible to load parts to the PT with names longer than 64 character.

Nevertheless I would be happy to hear some news here
Thanks for replay.

/Max

[Michael Heidemann]

We talk here about the part description (first line in the file) and not the filename!
http://www.ldraw.org/article/398.html

Code:

Where:
PartDescription is the descriptive name of the part (limited to 64 characters). If the part is good enough for public use, but has some deficiencies that need to be addressed, the text " (Needs Work)" (without the quotation marks) can be added to the end of the description. Please note that the full description including " (Needs Work)" is limited to 64 characters, so this decreases the usable portion of the description to 51 characters. If the description includes "(Needs Work)", a comment must be added to the file immediately following the official header describing the work that needs to be done.

[Max Martin Richter]

I'm Sorry, yes you are right. Can I delete or change my post to not confuse other people here?

/Max

[Michael Heidemann]

Just go to your post and hit the edit button - then delete what you want to delete.

[Steffen]

the discussion about a new limit is now ongoing in the lsc thread.
as i cannot post there, i post here.

as the parts tracker is easier to implement with _some_ limit than _none_,
i'd like to suggest 255.

[Tim Gould]

Why not truncate at 2047? That's close enough to infinite to effectively be no limit.

Tim

[Steffen]

I think that 255 already is *plenty*
(look at a 255 character long example string, you'll agree...).

While I'm writing this, I think we should maybe go for just 250,
to allow the leading "0 " in the line and maybe a leading "~" or "_" etc.,
to allow a trailing zero character (in C/C++ representation) and still be <= 255 for the whole line contents,
simply to avoid unnecessary trouble with existing tools (I know of no such trouble).

[Tim Gould]

My point is this: at some point 64 seemed great. Now it doesn't. 25X seems fine. Until it doesn't. 204X, however will likely be fine for essentially all time.

Tim

[Philippe Hurbain]

I kind of agree with Tim in the general case (remember the visionnary 640k memory limit of the IBM PC...
But I would not be against a 255 limit (or 200 for those who prefer decimal base) to avoid stupidly long descriptions. 64 is definitely too short, but even 100 would probably be OK.

[Tim Gould]

Stupidly long descriptions can and should (IMO) be discouraged in the specs and/or review process.

But we need to account for when you get a really specific variant print of something with an already long name. And having an artificially short limit might make that a hassle. Allowing effectively infinite length while encouraging brevity is more flexible IMO.

Tim

[Alex Taylor]

Exactly. If we set another arbitrary limit then we'll only have to go through this all over again some day. There is no good technical reason for there to be a limit so far as I know, so why impose one.

[Philippe Hurbain]

I meant on PT, not in the spec...

[Michael Heidemann]

In DATHeader now the max allowed length is Int32.MaxValue. It is not possible to store a larger string.

[Magnus Forsberg]

I want to chip in my two cents here.
I don't care if the upper limit is 100, 254 or 2 zillion.

The most common abbreviations are versions of "with/without", "pattern", and different colour names.
I think we need to agree on how to shorten names of colors. I dont want to see description with "Very_Light_Bluish_Gray and Speckle_Dark_Bluish_Gray_Silver Pattern" in them.

To me, a no limit policy, must mean that we no longer need unnecessary abbreviations, only clearer descriptions.
I think we need a statement that clearly state how words like the above should be written and be used.

Something like this:
"Pattern" must be added to all patterned parts.
"with" or "without" should not be shortened, but "w." or "w/o" is allowed. No other versions.

The description should IMO be kept below 64 characters, but an author is allowed to add more if, and only if, it is really necessary. It just need to make sense.

[Jaco van der Molen]

Recently I made some modifications to the Parts tree (groups) in MLCad. For example I wish to filter out all patterned parts in the Brick category using the search string "<Brick & !Pattern" in the rule for the Brick category in the Parts tree configuration. And so I have noticed some inconsistancy in part descriptions. Parts like:
- 3245bp02 Brick 1 x 2 x 2 w/ Inside Axleholder w/ Yellow Triangle Pat.
- 3066p01.dat Brick 1 x 4 without Centre Studs, LEGO Logo Open "O"/Red Patt.
in the list of parts that I want to filter out.
These two have a the word Pattern abriviated to Pat. and Patt. so they keep showing in the partslist.

I agree with Magnus there to be consistant in using abriviations.

[Steffen]

Exactly this abbreviation of "Pattern" to "Pat." or something else
is the reason why I wanted to drop the 64 chars limit.

Of course, I don't want ridiculous long titles now,
but I want keywords to be not abbreviated, exactly for the purpose
to be able to search properly for them.