+- LDraw.org Discussion Forums (https://forums.ldraw.org)
+-- Forum: Models and Parts (https://forums.ldraw.org/forum-18.html)
+--- Forum: Parts Authoring (https://forums.ldraw.org/forum-19.html)
+--- Thread: Naming Convention for Text Primitives (/thread-23035.html)
Naming Convention for Text Primitives - Ulrich Röder - 2018-11-20
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.cgi?f=p/typeswn7.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
RE: Naming Convention for Text Primitives - Magnus Forsberg - 2018-11-20
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.datBold otoh is more difficult to create by deforming.
RE: Naming Convention for Text Primitives - Ulrich Röder - 2018-11-20
(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.
RE: Naming Convention for Text Primitives - Chris Dee - 2018-12-16
(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.cgi?f=p/typeswn7.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}.datwhere 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?
RE: Naming Convention for Text Primitives - Ulrich Röder - 2018-12-23
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.
RE: Naming Convention for Text Primitives - Chris Dee - 2018-12-23
(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
RE: Naming Convention for Text Primitives - Chris Dee - 2018-12-29
(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?
RE: Naming Convention for Text Primitives - Travis Cobbs - 2018-12-29
(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?
RE: Naming Convention for Text Primitives - Ulrich Röder - 2018-12-29
...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?
RE: Naming Convention for Text Primitives - Magnus Forsberg - 2018-12-29
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?
RE: Naming Convention for Text Primitives - Ulrich Röder - 2018-12-29
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.
RE: Naming Convention for Text Primitives - Magnus Forsberg - 2018-12-29
(2018-12-29, 16:57)Magnus Forsberg Wrote: 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.
RE: Naming Convention for Text Primitives - Willy Tschager - 2018-12-29
(2018-12-29, 18:47)Magnus Forsberg Wrote: 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.
RE: Naming Convention for Text Primitives - Willy Tschager - 2018-12-30
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.
RE: Naming Convention for Text Primitives - Magnus Forsberg - 2018-12-30
(2018-12-30, 10:31)Willy Tschager Wrote: 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.
RE: Naming Convention for Text Primitives - Chris Dee - 2018-12-30
(2018-12-30, 11:16)Magnus Forsberg Wrote: 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.
RE: Naming Convention for Text Primitives - Magnus Forsberg - 2018-12-31
(2018-12-30, 10:31)Willy Tschager Wrote: ... 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.
RE: Naming Convention for Text Primitives - Chris Dee - 2019-01-16
(2018-12-29, 17:40)Ulrich Röder Wrote: 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}.datwhere 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.