Naming Convention for Text Primitives

[Ulrich Röder]

After having read....

http://www.ldraw.org/library/primref/#misctext

.....through these rules for the naming of text-primitives, I have discovered a mental conflict for me:

The identification of the style ("Bold", "Italic", "Condensed" .... and so on) remains to be missed.

and of course, and certainly, a combination of these different styles

How should that be handled?

As a recent example:

http://www.ldraw.org/cgi-bin/ptdetail.cg...peswn7.dat



| Type | Swiss BT | Number | "7" | Bold |

| type | sw | n | 7 | ? |



How should the "Bold" be included in the figuring?


"b" for Bold as an initial :   "b_typeswn7.dat"     <<< about like that?

or as appendix :                "typeswn7b.dat"        or better ...... 7_b?


It would be good to add a general definition to that, including a fixed letter choice for the styles.

Looking forward to a timely happy solution

[Magnus Forsberg]

Italic and Condenced fonts should be made by deforming the primitive.

Code:

1 16 0 0 0 1 0 0 0 1 0 0 0 1 typeswn1.dat
1 16 1 0 0 1 0 0 0 1 0 0 0 1 typeswn2.dat
1 16 2 0 0 1 0 0 0 1 0 0 0 1 typeswn3.dat
1 16 3 0 0 1 0 0 0 1 0 0 0 1 typeswn4.dat

1 16 0 0 1 1 0 .5 0 1 0 0 0 1 typeswn1.dat
1 16 1 0 1 1 0 .5 0 1 0 0 0 1 typeswn2.dat
1 16 2 0 1 1 0 .5 0 1 0 0 0 1 typeswn3.dat
1 16 3 0 1 1 0 .5 0 1 0 0 0 1 typeswn4.dat

1 16 0 0 2 .5 0 0 0 1 0 0 0 1 typeswn1.dat
1 16 1 0 2 .5 0 0 0 1 0 0 0 1 typeswn2.dat
1 16 2 0 2 .5 0 0 0 1 0 0 0 1 typeswn3.dat
1 16 3 0 2 .5 0 0 0 1 0 0 0 1 typeswn4.dat

Bold otoh is more difficult to create by deforming.

[Ulrich Röder]

Italic and Condenced fonts should be made by deforming the primitive.

Code:

1 16 0 0 0 1 0 0 0 1 0 0 0 1 typeswn1.dat
1 16 1 0 0 1 0 0 0 1 0 0 0 1 typeswn2.dat
1 16 2 0 0 1 0 0 0 1 0 0 0 1 typeswn3.dat
1 16 3 0 0 1 0 0 0 1 0 0 0 1 typeswn4.dat

1 16 0 0 1 1 0 .5 0 1 0 0 0 1 typeswn1.dat
1 16 1 0 1 1 0 .5 0 1 0 0 0 1 typeswn2.dat
1 16 2 0 1 1 0 .5 0 1 0 0 0 1 typeswn3.dat
1 16 3 0 1 1 0 .5 0 1 0 0 0 1 typeswn4.dat

1 16 0 0 2 .5 0 0 0 1 0 0 0 1 typeswn1.dat
1 16 1 0 2 .5 0 0 0 1 0 0 0 1 typeswn2.dat
1 16 2 0 2 .5 0 0 0 1 0 0 0 1 typeswn3.dat
1 16 3 0 2 .5 0 0 0 1 0 0 0 1 typeswn4.dat

Bold otoh is more difficult to create by deforming.

That was already in my mind .... so far .... when I pondered it, Magnus.

But doing that simply over the matrix does not give really nice and well matching results in relation to the original.
As you said ... with "Bold" it will be difficult and that's where the focus of my question lay.

I guess, a "Normal" and  a "Bold" Variation  of a Typegroup would be a good solution....and more clean.

[Chris Dee]

After having read....

http://www.ldraw.org/library/primref/#misctext

.....through these rules for the naming of text-primitives, I have discovered a mental conflict for me:

The identification of the style ("Bold", "Italic", "Condensed" .... and so on) remains to be missed.

and of course, and certainly, a combination of these different styles

How should that be handled?

As a recent example:

http://www.ldraw.org/cgi-bin/ptdetail.cg...peswn7.dat



| Type | Swiss BT | Number | "7" | Bold |

| type | sw | n | 7 | ? |



How should the "Bold" be included in the figuring?


"b" for Bold as an initial :   "b_typeswn7.dat"     <<< about like that?

or as appendix :                "typeswn7b.dat"        or better ...... 7_b?


It would be good to add a general definition to that, including a fixed letter choice for the styles.

Looking forward to a timely happy solution

This was defined in era of the 8.3 naming restrictions. I'd be happy to extend this to include the font (typeface) name, e.g. type-swissbt-bold-n7.dat

The general case would be

Code:

type-{fontname}-{style}-{glyph-class}{character-code}.dat

where style is (nornal, bold, italic, etc) glyph-class is (u=upper case letter, l=lower case letter, n=number, s=symbol, a=upper case accented letter, b=lower case accented letter) and character-code is the glyph identifier (a-z for the upper and lower case letters, 0-9 for the numbers, arbitrary for symbols).

Now would be the time to fix this before Uli's Swiss BT primitives get released. I can do the renames.

Comments?

[Ulrich Röder]

I think it would be good this way, Chris ... clear and easy to see.

So... the option is also given, to include extreme rare variants of writing forms ..... as well as "extra bold" .... if that should be the case sometime.

[Chris Dee]

I think it would be good this way, Chris ... clear and easy to see.

So... the option is also given, to include extreme rare variants of writing forms ..... as well as "extra bold" .... if that should be the case sometime.

Yes, like e.g. type-swissbt-extrabold-n7.dat

[Chris Dee]

I think it would be good this way, Chris ... clear and easy to see.

So... the option is also given, to include extreme rare variants of writing forms ..... as well as "extra bold" .... if that should be the case sometime.

Yes, like e.g. type-swissbt-extrabold-n7.dat

Uli has also recognised that this does not encode the glyph colour, so because colour 16 is used for the background, we cannot use the existing files to render white text.

We could a) separate the foreground from the background two have two files for each glyph which can then be coloured independently, or b) duplicate the files, where necessary, for each additional colour.

Also, should we use a consistent height across all files? The Stencil glyph files use a height of 10LDu and reduce, wheras the new SwissBT glyph files use a height of 1LDu and enlarge.

Or is this all getting unnecessarily complex and we should just inline?

[Travis Cobbs]

Uli has also recognised that this does not encode the glyph colour, so because colour 16 is used for the background, we cannot use the existing files to render white text.

We could a) separate the foreground from the background two have two files for each glyph which can then be coloured independently, or b) duplicate the files, where necessary, for each additional colour.

Wouldn't it make more sense for the glyph and the background to be two separate subparts, and then the full symbol file would simply refer to the two subfiles with appropriate colors?

[Ulrich Röder]

...by the way....consistent height

when using txt2dat in LdPartEditor the  height of upper  and lower Glyphs is absolutly identic....when writing them separatly.

Only when writing them  together the relation of the different heights is given.

A nice Trap...and important to keep that in mind for the different cases.


But back to the core about this thread:

Which decision consumes less resources..will mean efficiency..and which one less stress ... means effectiveness?


....out of the belly .... I also tend to divide the glyphs .. for easy handling.



OTOH .... just a file, only where it is necessary to copy and change the color in the editor .... is done quickly ....

.... but then we need a color appendix or prefix in the filename, for the resulting new primitive.

... and would it not be better to label the characters (comma, percent, dot, exclamation ect.) ... with consecutive (each the next free) numbering?

[Magnus Forsberg]

Pardon me, but I dont like this at all. I like standardization, but to me these are all just subfiles to a few specific stickers.
Why should we a have a complete set of primitives, in different styles and classes, for every typeface, maybe only used in a single sticker? The Stencil typeface is only used in a single print and never again.

I can see a difference here in this  sticker sets. Both are some sort of list of cities and trainnumbers.
But are they ever going to be used again? Is this typeface some sort of standard typeface often used by LEGO?

Maybe we know of a document were LEGO say that sticker all use this typeface?

[Ulrich Röder]

can be seen this way .... for sure ....

But almost the whole "Gray train era" is specially made with this font.

However....Would be nice if there could rise soon a clear and effective decision and therefore a solution to generally get on with it .... for all font types.

[Magnus Forsberg]

The Stencil typeface is only used in a single print and never again.

I'm sorry Willy, but the print on this tile, 3069bpw0, is one I would like to rework. It has many overlaps and tiny gaps.
Or would you rather do it yourself? L in Flatfoot is the worst example.

But it is also a good example of how I would like to see a typeface primitive used. The letters are all scaled into many different sizes, widths and shapes.

[Willy Tschager]

I'm sorry Willy, but the print on this tile, 3069bpw0, is one I would like to rework.

Do with it whatever you want.

w.

[Willy Tschager]

But before you start working I'd like to know if you are going to fix only the tile or also the text primitives as I reuse them on this:

   

w.

[Magnus Forsberg]

But before you start working I'd like to know if you are going to fix only the tile or also the text primitives as I reuse them on this:



w.

If I understand Chris correctly they will all need a recycling through the Part Tracker anyhow.
It looks like the major issue is internal T-junctions in the letter primitives. A simple substitution of 2-4disc =>2-chrd primitives.

I'll dig into the letter prims, but I will not upload any ahead of a renumbering by Chris.

[Chris Dee]

If I understand Chris correctly they will all need a recycling through the Part Tracker anyhow.

Not necessarily. We don't need to move these 21 files merely because we have evolved the naming convention. So please go ahead and fix any problems using the existing filenames.

[Magnus Forsberg]

... going to fix only the tile or also the text primitives as I reuse them...

I've now had a look into all the text prims. I found four I want to fix. The letters B, O, T and Y.
B and T have some internal unmatched primitives and T-junctions.
O and Y have a bad corner, that might affect the design you're working on.

I'll fix the overlaps and gaps in the tile, and also the letters mentioned.
I see no need to recycle the rest of the letter prims only to replace 2-4disc with 2-4chrd.

[Chris Dee]

can be seen this way .... for sure ....

But almost the whole "Gray train era" is specially made with this font.

However....Would be nice if there could rise soon a clear and effective decision and therefore a solution to generally get on with it .... for all font types.

I think I have given this enough time for discussion, with no further responses. So I wil go ahead with:

The general case would be:

Code:

Code:

type-{fontname}-{style}-{glyph-class}{character-code}.dat
type-{fontname}-{style}-{glyph-class}{character-code}-{colour-code}.dat

where style is (normal, bold, extrabold, italic, etc) glyph-class is (u=upper case letter, l=lower case letter, n=number, s=symbol, a=upper case accented letter, b=lower case accented letter) and character-code is the glyph identifier (a-z for the upper and lower case letters, 0-9 for the numbers, arbitrary for symbols). The default colour will be black with colour 16 background. The [-{colour-code}] extension can be used for additional colours, for the few cases it is needed.

I will rename the existing SwissBT files and update the dependencies.