LDraw.org Discussion Forums

Full Version: Naming Convention for Text Primitives
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2
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
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.
(2018-11-20, 16:39)Magnus Forsberg Wrote: [ -> ]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.
(2018-11-20, 4:01)Ulrich Röder Wrote: [ -> ]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?
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.
(2018-12-23, 0:10)Ulrich Röder Wrote: [ -> ]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
(2018-12-23, 7:24)Chris Dee Wrote: [ -> ]
(2018-12-23, 0:10)Ulrich Röder Wrote: [ -> ]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?
(2018-12-29, 8:01)Chris Dee Wrote: [ -> ]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?
...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?
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?
Pages: 1 2