To font or not to font

[Orion Pobursky]

Should all the parts that use Swiss 720 font be required to use the handful of primitives we have already added to the library (before we decided that doing so wasn't desired)? I thought we settled this debate as "No" but the issue has cropped up again.

My stance is that it is at the option of the author and lack of use does not constitute a "Hold". This will be the official guidance on the matter unless consensus takes us in a different direction.

[Philippe Hurbain]

Should all the parts that use Swiss 720 font be required to use the handful of primitives we have already added to the library (before we decided that doing so wasn't desired)? I thought we settled this debate as "No" but the issue has cropped up again.

My stance is that it is at the option of the author and lack of use does not constitute a "Hold". This will be the official guidance on the matter unless consensus takes us in a different direction.

IMHO the font subtiles should be used only if the author for some reason can't use txt2dat. Definitely, not using the subfiles shouldn't be a problem!

[Orion Pobursky]

I'd also like to point out that lack of 100% primitive efficiency have never been reason for a part Hold

[Magnus Forsberg]

I see no reason for a Hold vote, if the primitives are not used.

But I think Willy is "half-right".
In the actual case the letters are not made from an inlined, official primitive. They are much more hi-res.
If I understand Willy correct, the primitives should be updated and use the mesh from these stickers.
And then it would be OK to use the content inlined as in this sticker.

[Willy Tschager]

I do not HOLD if an author hasn't used a box or cylinder or whatever prim could be used, but I do with letters 'cos there is one thing that differs: detail and the related poly-count.

There's another thing. I don't mind if an author wastes its time recreating all the letters time and again when stitching together those sticker from the 80s where Swiss 720 was apparently the main font used - but (there is always a but) he is also wasting my time: I have to check all letters for overlap which isn't detected by Edger and other things. Checks I don't have to do when an already certified prim is used. As we know the number of letters and numbers sum up quickly:

https://www.ldraw.org/cgi-bin/ptdetail.c...63555b.dat

As for the HELD sticker:

https://www.ldraw.org/cgi-bin/ptdetail.c...63345e.dat

to me it is pure nonsense not completing the already existing set of typefonts 'cos we decided to no longer add typefont prims to the library. I'm perfectly fine with not adding NEW fonts but what we gain not completing the Swiss 720 with already 4 official lower case letters in the library? There's more. Looking at Takeshi's "United" I'd say that the resolution and the number of polygons to mimic the font is better that the prims of the upper case letters we currently have and updating them as we go should be considered.

w.

[Orion Pobursky]

wastes its time recreating all the letters time and again when stitching together those sticker

My rebuttal to this is that txt2dat exists and should be used. Having authors stitch together the letters piecemeal leads to the spacing and kerning inconsistencies that had us decide to not include fonts in the first place.

[N. W. Perry]

My rebuttal to this is that txt2dat exists and should be used. Having authors stitch together the letters piecemeal leads to the spacing and kerning inconsistencies that had us decide to not include fonts in the first place.

I have yet to get usable results from txt2dat (via LDPE). Now I have more work to do on this, and not to say that things should be designed around my personal workflow, but perhaps the takeaway is that the LDraw policy should accommodate the widest possible range of workflows. If there are approved prims that could be placed in even a standard text editor, that's more inclusive than relying on a specific tool on the author's end.

I also think that having a complete, hi-res fontset, even of only one typeface, would set a good standard on how to build patterns from other fonts when necessary (such as expected resolution of curves, standardized base size, how/when to use 2d primitives, etc.).

That would give part reviewers a good standing to say things like, "your letters could be improved; check out the official primitives for ideas on how to do this." You could even use an existing primitive as a base to model the same character in a different font, without having to start from scratch every time.

[Orion Pobursky]

I'm not arguing against the font primitives, they certainly can be used, I'm arguing to leave that option to the parts author.

[Takeshi Takahashi]

I'm not against with font prims and I agree that they are very useful and time-saving to create text-intensive patterns (like timetable etc.).
I think the way to create text patterns should be chosen on the author's discretion, as far as complying with the parts regulations.
1) Use font prims straightforward
2) Inline and modify font prims (colour variants, negative kernings etc.)
3) Use raw or optimized txt2dat output
4) Trace manually from the pattern image

Fortunately I have a number of TrueType font library on my workstation and am able to generate text patterns by txt2dat,
but many authors don't have suitable fonts and these prims would be so helpful.