[metapost] Glyph and display and 3D fonts

[Laurence Finston]

I've attached an example of something I've been working on.  It is my first attempt at a "3D" display font.  There's a great deal of work left to do but I'm posting this message in case anybody might be interested or even have a use for such a font.

The first page of hollow.pdf shows the characters 65, 67, 68 and 69 of the MF font "hollow", i.e., hollow.600pk.  The following pages show corresponding MetaPost figures.  The source code is in hollow.mf and hollow.mp, respectively, which are also attached.  These files, however, are generated by GNU 3DLDF from the source file hollow.ldf, which is also attached.

The character is from Computer Modern Sans Serif Bold Extended 10pt (cmssbx10), but I've straightened out the curves at the top and the base, so it consists entirely of straight lines. 

The syntax of 3DLDF is similar to that of MF/MP, with some differences, however.  The input between beginfig and endfig in hollow.ldf is written to hollow.mp while that between beginchar and endchar is written to hollow.mf.  Then, the font is generated in the usual manner:

mf hollow.mf
gftopk hollow.600gf

Then, in hollow.tex (attached), it can be used, also in the usual way:

\font\hollow=hollow

{\hollow\char65} % or whatever

The source code and various other files can be found in the Git repository for 3DLDF:  https://git.savannah.gnu.org/cgit/3dldf.git

It's in the directory 3dldf/src/Outline_Fonts/Hollow/.

The first character on page one of hollow.pdf is non-3D and has no crossing paths, so it fulfills the requires of mf2pt1, as long as it's small enough:  mf2pt1 will fail for sizes for which MF itself will succeed when using 600dpi (mode ljfour).  However, it doesn't matter because the character can be scaled down to whatever size necessary within 3DLDF before writing the MF code to the MF output and the generated PS font can, of course, be magnified or shrunk to one's heart's content.

The following 3D characters, however, are drawn using crossing paths, so they won't work with mf2pt1.  It might be possible to turn them into non-crossing ones, but I think it would be difficult and this isn't very high on my list of things to do.

The surface hiding was done by hand and if the letter was put into positions that differ too much from the ones shown, I would have to change the order in which the paths are unfilled and drawn.  Incidentally, while drawing and unfilling worked just fine for the MP figures, I had to change 3DLDF so that it would write "cullit;" after every draw and unfill command in the MF output.

3DLDF doesn't implement surface hiding and this is not a trivial problem.  I think the best approach would be to have it send output to an external rendering program, such as Blender, rather than implementing it within 3DLDF.  I have no idea at the present time how I could get such a rendered image back into 3DLDF and use it for fontmaking.

It would, of course, be possible to put curved characters into perspective for a 3D font.  This is something else I've been working on.  It was necessary to implement "resolving" a path, i.e., adding more points so that the curve wouldn't "go out of shape" when applying the perspective projection to it.  This is because MP uses Bézier curves, which are not invariant under non-affine transformations like the perspective projection, rather than non-rational uniform b-splines (NURBS), which are.

In addition, it would not be possible to do surface hiding by hand for letters with curves:  For one thing, it's not trivial finding the apparent edge of an arbitrary curved surface as viewed from a particular position.

If anyone has questions I'll be glad to answer them and any feedback would be much appreciated.

Laurence 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hollow.ldf
Type: application/octet-stream
Size: 23628 bytes
Desc: not available
URL: <https://tug.org/pipermail/metapost/attachments/20220424/b5d60f86/attachment-0003.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hollow.mf
Type: application/octet-stream
Size: 14795 bytes
Desc: not available
URL: <https://tug.org/pipermail/metapost/attachments/20220424/b5d60f86/attachment-0004.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hollow.mp
Type: application/octet-stream
Size: 54706 bytes
Desc: not available
URL: <https://tug.org/pipermail/metapost/attachments/20220424/b5d60f86/attachment-0005.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hollow.pdf
Type: application/pdf
Size: 25143 bytes
Desc: not available
URL: <https://tug.org/pipermail/metapost/attachments/20220424/b5d60f86/attachment-0001.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hollow.tex
Type: application/x-tex
Size: 3752 bytes
Desc: not available
URL: <https://tug.org/pipermail/metapost/attachments/20220424/b5d60f86/attachment-0001.tex>