David, thanks for looking at this. I know the dimensions -- it is my font. The collectbox package was written by Martin Scharrer, and claims to be compatible with all versions of LaTeX (DVI-LaTeX, pdfLaTeX, XeLaTex and LuaLaTex) and does not rely on any other packages. Making another font would not solve the problem, the symbols have their dimensions by design. The sidebearings are picked up and so there is no problem horizontally. It is vertical matching. LaTeX picks up the actual top and bottom of the bounding box, so I have to change that. So far no problem with the solution I posted.

@MichaelLeeFinney sorry I do not understand your comment at all. The collectbox usage in your answer doesn't seem that related to the question, it is certainly not doing what is asked which is altering the glyph metrics.

David, but it is. It has altered the bounding box that TeX uses to typeset the line. This allows me to have a string of symbols which have varying depth and height metrics, and to reliably put them in a string and all be treated identically with the same depth and height metrics. It does not alter the font itself of course. The change is seen in the fbox frame in my answer compared to my question. That frame represents the metrics used for the bounding box. The horizontal was always correct since it is taken from the font. But there is no equivalent for vertical metrics.

@MichaelLeeFinney no your question asks how to set the height and depth for a glyph, and my answer points out that (aside from luatex) glyph metrics are read only. Your answer does something entirely different, it sets a box with externally assigned height and depth, that is of course possible in tex. Now in your example the box may have content just a single character but that is not really that relevant to the construction. So your answer may be what you need which is fine, but it doesn't answer the question that you actually asked (also no one can run the example code without the font)

David, I may have not been clear about what I was asking -- but this is exactly what I wanted. I wanted to take a glyph from my font and put in a box lying to TeX about its actual depth and height -- but allowing the ink to spill over. I thought that I was clear, but for practical purposes I'm not sure there is a difference between what I said and what I want. As far as the font is concerned, I am working hard to get ready to put it on CTAN. I am working on the documentation and trying to clear up a couple final points that I want handled first.

@MichaelLeeFinney when you say latex picks up the actual dimensions of the bounding box, it does not access the visual bounds, it just uses the height and depth of the character bounds as specified in the font, so if the original font specified the height and depth of the characters as the same, with the arrows extending beyond that then the \fbox would have worked with no extra tex positioning.

I have just double checked, and the only information that you can supply to the font about a glyph is the sidebearings, advance width, shape, hinting and kerning (and possibly color). Extracting the character from an UML representation shows that only the advance width and shape is stored. Even the side bearings are computed. Since TeX is clearly creating its box based on side bearings and the actual shape, it is not using the font-wide descender and ascender information for that purpose. While there is no (visual) bounding box specified in the font, TeX does appear to be computing one.

Would you like to move this discussion to chat?

yes I suppose I gave the classical tex answer (where tex only has the font metrics and doesn't load the font at all) you still haven't said whether you are using xetex or luatex, I'll need to check how they infer vertical size if the font doesn't specify it....

I am using LuaLaTex, but XeLaTeX works as well. My understanding (which may be wrong) is that TeX does create a "character box", but you can't do anything with it. Here is the complete information maintained in the font for that character. You can see that LuaTeX must be computing the information to get the fbox dimensions.

  {
    "name":"KntTSLABSLA",
    "unicode":"e1d0",
    "lastModified":"2019-05-26 00:11:02",
    "layers":[
      {
        "name":"Regular",
        "advanceWidth":1000,
        "elements":[
          {
            "elementData":{
              "contours":[
                {
                  "nodes":[
                    "324 812 {n:'sv01'}",
                    "651 931",
                    "668 884",
                    "470 812",
                    "1050 812 {n:'dv04'}",
                    "1050 712 {n:'dv03'}",

it's a node not a box, but yes

Please understand that I have only been using LaTeX for less than a year. I learned it last summer and have used it for most of my assignments in college (I have returned to get a math degree). I have been building this font for nearly two decades (not originally Unicode) because I kept finding symbols not in Unicode that I needed. I have always intended to make the font public, but for my math honors project I have created over 200 symbols fo

@MichaelLeeFinney just checked, tfm fonts and truetype have per character height information but type1 fonts (and otf fonts using type1 paths dont) the luatex manual says:

@MichaelLeeFinney so in classical tex for all fonts you can assert the bounding box of each glyph independently of its actual shape, but for luatex/xetex you can only do that for truetype and truetype based opentype fonts

for that project and now publishing the font has become critical. I have not yet learned TeX, although I suspect that will come in time. In the meantime, this was the last issue that I needed to resolve to publish the font thanks to the kind help of several people here (including yourself). The solutions are not necessarily optimal but they work. I would be very happy for someone who knows that they are doing to review things before I sumbit to CTAN. Why can I see the bottom of my typing?

That makes sense, I suspect that when a true type font is generated, the per glyph bounding box is computed. The data I sent you was the master FontLab data that it maintains for the font. But, regardless how computed that bounding box would still include the entire character. I don't think it is possible to set the box differently. And really, you wouldn't want to. Changing the box that TeX is using for typesetting is better. Otherwise you could get have problems with some display engines.

@MichaelLeeFinney not sure I understood the typing question but there is a characterlimit on posts in chat

Yes, I found that out. My typing box is longer than the window so when I reach a certain point, I can no longer see what I am typing. Expanding the windows using the bottom right handle does not help.

But whether the bounding box is computed or stored, or whether I change it in the font or change it by wrapping another box around it, still gives the same result. I get an effective bounding box that is 1em x 1em square with the ink spilling over the sides. That is exactly what I need to use symbols for drawing. I know that there are other ways of drawing, but this is very simple (and not unique, there are sets of drawing symbols in Unicode) and easy for other researchers to use.

Using a graphics package is more complex, harder to automate and nobody wants to do it by hand. For simple cases, it is not a big deal, but more complex cases would be a nightmare. My advisor, who has used LaTeX for years was excited by this approach and thinks that it will be very useful.

If there are better ways to get that 1em x 1em bounding box, I would be overjoyed to learn about them. This is the only approach that I have found so far. LaTeX is sorely lacking in precision typography -- although it is possible or stretchy characters wouldn't work.

Interesting -- I just replaced the .otf with a .ttf (both Unicode) and tried my initial example. It gave the result that I needed, so it must be picking up the font depth and height (descender and ascender). I opened up the TrueType font using FontForge and it does have a height and depth you can fill in. If it "guesses" you get the same thing as for the OpenType. If not filled in, you get the font's values. So that would allow overriding for TeX. Setting that field did not make any changes.

So the TrueType and OpenType fonts compute different bounding boxes (as shown by fbox). Strictly speaking, the OpenType is more accurate and what should normally be used.

Further investigation shows that FontForge retains a change, but does not export it to the TrueType font. So this is an observable difference between TrueType and OpenType fonts. That difference can and will affect the layout. Something to keep in mind.

so are you also planning a type1 version, and pdflatex support ? (shouldn't be too hard if there are less than 256 characters)

No, I am not -- there are over 4000 symbols in the font. I went to Unicode because the number of 256 character fonts got out of hand. As far as I am concerned Unicode is the future, and -- while I am not totally sure -- I think that the LaTeX3 project is based on Unicode as well. I just discovered I was wrong about the previous test. I will need to redo it (I incorporated my fix in the .sty file and forgot to remove it for the test). I will let you know on that.

@MichaelLeeFinney ah I thought you mentioned 200 above:-) OK well yes I agree that unicode is the future, but most journal publishers are not there yet, so those that accept latex submission at all mostly require pdftex (this includes the AMS for example) but with that many glyphs I agree that pdftex support is probably more painful than it is worth. (I do know something about the latex3 project, having been in it since 1991 or so:-)

The 200 (actually over) is just for the symbols added for my honors project. There are additionally 63 stretchy delimiters and around 1,000 extra symbols just for that. Then there are hundreds of arrows, geometric symbols and so forth. While all of them are not exported in the .sty file, most of them are. So is LaTeX3 based on Unicode? And will it be upward compatible from either LuaLaTex or XeLaTex? Will it include the Lua scripting language?

@MichaelLeeFinney the top level interfaces are not done but yes there will be a compatible interface. lualatex and xelatex already depends greatly on fontspec/unicode-math both of which written in expl3. but latex is written in tex so if it runs over pdftex it is fundamentally an 8bit system and latex3 can not change that.

I thought that expl3 was written in TeX. If not, what was it written in? First test without setting anything in the truetype flle does give exactly the same results as the opentype file. So, no differences using defaults.

@MichaelLeeFinney yes it's written in tex, so its unicode support is limited by the unicode support of the tex engine it is running over, classic tex or pdftex are 8bit, luatex and xetex are unicode, ptex and uptex are a kind of strange mix

It turns out that FontForge does not export that information to TrueType files, so in practice there is no difference using either FontLab or FontForge. I don't think that I have any other font editors. Possibly those fields only exist in the older 256 character TrueType fonts? I would have started using LaTeX years before I did, but did not because of lack of Unicode support. The original TeX font system is simply archaic and really not very usable.

Certainly archaic, but "not usable" is somewhat contradicted by millions of published documents.

Since AMS has the STIX2 font (and I think has obsoleted the older 8-bit STIX fonts), I would certainly hope that publishers will accept LuaLaTeX or XeLaTex, because I won't be publishing using anything that doesn't support Unicode. I made the metrics compatible with STIX2 since that should be an acceptable font for AMS publishers ( and I would mostly be publishing math or logic -- hence the name of the font). It started out because I needed arrows, arrows, arrows -- with only a few in Unicode.

The AMS spearheaded much of the development of stix, but (last I heard) they did not use xetex or luatex in production.

Not usable for me without far too much effort, and I suspect that is true for more and more people. If they don't use XeLaTeX or LuaLaTeX in production, I am not sure what the point of their spending so much time and effort on the STIX fonts might be. Or perhaps they are planning a move and wanted to be prepared for it?

@MichaelLeeFinney exactly. Unicode is the future, but math typesetting is still better in pdftex. people are working on it but publishers are very conservative and in this case it is hard to argue

For me, it is back to the old days, when mathematicians invented symbols on the fly. When I need a new symbol, I just add it to my font. Unicode has done a pretty good job for symbols for mathematics -- but less so for logic.

@MichaelLeeFinney but I'm intrigued how do you manage a font of thousands of arrows, most documents that I see with lots of arrows are using commutative diagrams or similar so can get many arrow forms from tikzcd or xypic etc

I thought that LuaLaTeX was based on pdfTeX? And as such should do just as well for typesetting? And from what I have seen on the web comparing XeLaTex and LuaLaTeX there is very little if any difference between them. In any case, nothing that I can detect in what I write.

if you use lualatex out the box then it uses 8bit fonts and tex's classic math layout for math if you load unicode-math package and an opentype Math font then it uses a more or less completely different math layout engine that is in the same executable, there are still multiple edge cases (partly because the original microsoft spec of the Opentype math table is somewhat vague)

There are not thousands of arrows, but certainly hundreds. Many of those are glyph variants which are not directly available by the .sty file. However, there are, I think, 75 published arrows. But there are many more in reserve. For example, sometimes you need multiple ordering symbols. I have a couple of dozen or so. I don't have names for many of them, future releases will probably export more of the unnamed glyphs.

I know about the MATH tables. Apostolos Syropoulos helped me getting started, they are a pain to work with. He uses FontForge which has direct support whereas FontLab does not. And had a bug (which they fixed). Right now I maintain the MATH table separately from the font, and use the TTX utility to insert it because it understands names and FontLab doesn't (yet, they are working on it).

As an example of insufficient arrows, I have 14 just for different logics. When working with multiple logics you want to distinguish what you are using. So the are 7 left to right arrows and 7 bidirectional arrows. Not exported (yet) are the matching 7 right to left arrows. Then you need to distinguish between sequents, assertions, models and consequence relations. There are another 8 there. And again, related but non-exported versions.

For the unexported symbols I need some type of reasonable name. That takes a good bit of effort, and the additional symbols can wait for future releases as I get time. Also, some of them will need some work to make them look reasonable. Originally, I only considered how they looked on the display and not on paper, so sometimes the contours are not optimal.

Not to mention that the font can use some professional kerning and hinting, neither of which I have done. I do have some kerning, and understand that -- but it is a huge effort. Hinting is done automatically by FontLab and looks pretty good -- but I'm sure could be better. Still, it looks good on paper and display and the included scripts (20, I think) work for their intended purpose.

Another thing that Unicode is missing for logic is complete script sets (just the alphanumeric characters). I use sans serif, slab serif and normal italic where each of them has four variants. Unicode doesn't always have all of the letters, sometimes none of the digits or all of the variants. Bad Unicode! Include all of it. The focus in Unicode for scripts is using single letters as names -- but that is like programming in FORTRAN with single letters. You need more.

@MichaelLeeFinney yes they are weirdly inconsistent and inconsistently specified, originally unicode-math used the bold alphabet for \mathbf but most fonts only set them up for single characters, so no kerns or ligatures, so now \symbf uses the math alphabet block allowing \mathbf to be defined as in classic tex to use a separate bold font with proper multi-letter support

I have tried to match that, but for my font both the sym and math versions give the same result, but at least the macros work. I don't know how to distinguish the behaviors yet. Right now, the side bearings for the scripts are set more generically, so kerning isn't as important yet. Also unicode-math makes arbitrary decisions on italic vs non-italic trying to match mathematical practice, I do not do that -- there is no corresponding practice in logic (that I have seen).

I have enjoyed the chat, and would look forward to another. Unfortunately, I need to eat breakfast and then go get my daughter's monitor, which failed, and see if I can repair it. Maybe, maybe not. We can also chat via email if you would like -- I am using ctan@metachaos.net for email related to CTAN and this topic in general.

Ok bye