Merged font bug: Wrong metrics and missing glyphs?

[RuixiZhang42]

I dug a little further from our discussion on the “slightly larger intermediate parentheses”. In my previous comment I mentioned that

We can see that yhcmex10’s \bigg is slightly smaller than cmex10’s \bigg […]

This appears to be a yhcmex10 font bug after all. In the following example, I found that:

1. All intermediate sizes — numbered “4” — meant to be between \Big and \bigg, were vertically off-center (metrics wrong?);
2. All \bigg sizes — numbered “5” — were stuck at the previous smaller sizes and did not grow (glyphs missing?). The vertical placements were also wrong.

The second point now fully explains why TeX chooses the larger (and unpleasing) parentheses in \binom: TeX was supposed to choose \bigg, but it turned out that \bigg was mis-mapped to a smaller size and was not big enough. So TeX proceeded to the next bigger size available, the intermediate one (numbered 6, between \bigg and \Bigg).

I have highlighted the problematic sizes in orange.

\documentclass{article}
\usepackage{xcolor}
\usepackage{yhmath}
\newcommand*\vcontent[1]{%
  \hrule height
  \ifcase#1 1.0em%  0: Normal size without extension
  \or       1.2em%  1: \big
  \or       1.5em%  2
  \or       1.8em%  3: \Big
  \or       2.1em%  4
  \or       2.4em%  5: \bigg
  \or       2.7em%  6
  \or       3.0em%  7: \Bigg
  \or       3.6em%  8
  \or       4.2em%  9
  \or       4.8em% 10
  \or       5.4em% 11
  \or       6.0em% 12
  \or       6.6em% 13: Largest size available in yhcmex10
  \or       7.2em% 14: Piecing parts together
  \else       0pt%
  \fi
  width 0.4pt\relax
}
\newcommand*\test[3]{%
  \kern-\nulldelimiterspace
  \left#1%
  \vcenter{\color{red}\vcontent{#3}\hbox{\smash{\color{blue}#3}}}%
  \right#2%
  \kern-\nulldelimiterspace
}
\pagestyle{empty}
\begin{document}
\(
()%
\test(){ 0}%
\test(){ 1}%
\test(){ 2}%
\test(){ 3}%
\test(){ 4}%
\test(){ 5}%
\test(){ 6}%
\test(){ 7}%
\test(){ 8}%
\test(){ 9}%
\test(){10}%
\test(){11}%
\test(){12}%
\test(){13}%
\test(){14}%
\)

\(
\langle\rangle
\test<>{ 0}%
\test<>{ 1}%
\test<>{ 2}%
\test<>{ 3}%
\test<>{ 4}%
\test<>{ 5}%
\test<>{ 6}%
\test<>{ 7}%
\test<>{ 8}%
\test<>{ 9}%
\test<>{10}%
\test<>{11}%
\test<>{12}%
\test<>{13}% Stop growing afterwards
\)

\(
/\backslash
\test/\backslash{ 0}%
\test/\backslash{ 1}%
\test/\backslash{ 2}%
\test/\backslash{ 3}%
\test/\backslash{ 4}%
\test/\backslash{ 5}%
\test/\backslash{ 6}%
\test/\backslash{ 7}% Stop growing afterwards
\)

\(
\{\}%
\test\{\}{ 0}%
\test\{\}{ 1}%
\test\{\}{ 2}%
\test\{\}{ 3}%
\test\{\}{ 4}%
\test\{\}{ 5}%
\test\{\}{ 6}%
\test\{\}{ 7}% Pieced together afterwards
\)
\(
[]%
\test[]{ 0}%
\test[]{ 1}%
\test[]{ 2}%
\test[]{ 3}%
\test[]{ 4}%
\test[]{ 5}%
\test[]{ 6}%
\test[]{ 7}% Pieced together afterwards
\)

\(
\lfloor\rfloor
\test\lfloor\rfloor{ 0}%
\test\lfloor\rfloor{ 1}%
\test\lfloor\rfloor{ 2}%
\test\lfloor\rfloor{ 3}%
\test\lfloor\rfloor{ 4}%
\test\lfloor\rfloor{ 5}%
\test\lfloor\rfloor{ 6}%
\test\lfloor\rfloor{ 7}% Pieced together afterwards
\)
\(
\lceil\rceil
\test\lceil\rceil{ 0}%
\test\lceil\rceil{ 1}%
\test\lceil\rceil{ 2}%
\test\lceil\rceil{ 3}%
\test\lceil\rceil{ 4}%
\test\lceil\rceil{ 5}%
\test\lceil\rceil{ 6}%
\test\lceil\rceil{ 7}% Pieced together afterwards
\)
\end{document}

[norbusan]

Could this be an error in the type1 font which is not present in the original metafont sources?

[RuixiZhang42]

Could this be an error in the type1 font […]?

AFAICT, the \big (1.2em), \Big (1.8em), \bigg (2.4em) and \Bigg (3.0em) are supposed to take glyphs from cmex10 directly. But for some reason, \bigg selects the 2.1em size in yhcmex10.

• The blue-shaded glyphs are the intermediate ones: 1.5em, 2.1em and 2.7em.
• The red-circled glyphs are all at 3.0em. This is strange, because the 3.0em size already exists in cmex10 via \Bigg.
• The other glyphs (radical signs excluded) are the large ones: 3.6em, 4.2em, 4.8em, 5.4em, 6.0em and 6.6em.

[RuixiZhang42]

The radical signs experience the exact same problem:

Technical note: When the vertical content is of size n, the radical sign is of size n+1.

Again, the intermediate size (numbered “4”, produced by “3”) appears to be vertically off-aligned (it should be slightly lower IMHO). On the other hand, the supposed \bigg size (numbered “5”, produced by “4”) doesn’t change size and it is from yhcmex10, when it should have been the slightly larger version from cmex10 (both slightly taller and deeper).

These two phenomenons combined to create the “sudden deepening” of the radical signs, which is really unpleasing:

% Insert the following code to the MWE above
\newcommand*\testsqrt[1]{%
  \sqrtsign{%
    \vcenter{\color{red}\vcontent{#1}%
      \hbox{\smash{\color{blue}\the\numexpr#1+1\relax}}}%
  }%
}
\(
\testsqrt{ 0}% From cmex10
\testsqrt{ 1}%
\testsqrt{ 2}% From cmex10
\testsqrt{ 3}%
\testsqrt{ 4}% NOT From cmex10 ???
\testsqrt{ 5}%
\testsqrt{ 6}% From cmex10
\testsqrt{ 7}%
\testsqrt{ 8}%
\testsqrt{ 9}%
\testsqrt{10}%
\testsqrt{11}%
\testsqrt{12}%
\testsqrt{13}%
\)

[norbusan]

First of all I confirm that the metafont sources contain the same error

So we need to fix the metafont sources and the type1 font. Nice project ;-)

I asked Yannis to also look here, we will see.

Thanks for your research and help!.

[norbusan]

Hmm, strange. Looking at the generated glyphs it does seem correct, though ...(running mf-nowin and gftodvi). What would you say?
out1.pdf

[RuixiZhang42]

I’m afraid that my metafont knowledge is extremely limited.

Yes, the glyphs do exist — TeX just doesn’t choose them… Could it be the problem with the chain of linking the next large delimiter?

charlist oct"000": oct"200": oct"020": oct"201": 
oct"022": oct"202": oct"040": oct"203": 
oct"204": oct"205": oct"206": oct"207": oct"210": oct"211":
oct"060";  % left parentheses
...

and the series of NEXTLARGER instructions. As I observed, '203 and '040 are actually the same size.

---

On the other hand, in terms of the metrics, at the '200 position (1.5em left parenthesis) we have

(CHARACTER O 200
   (CHARWD R 0.527781)
   (CHARHT R 0.039999)
   (CHARDP R 1.490013)
   (NEXTLARGER O 20)
   (MAP
      (SELECTFONT D 1)
      (SETCHAR O 200)
      )
   )

Shouldn’t the CHARDP be something like 1.460013 (about 1.5-0.039999)? Similar issues exist for others as well. For instance,

• CHARACTER O 201’s CHARDP should be around 2.06 — this corresponds to the “4” size.
• CHARACTER O 22’s CHARDP should be around 2.36 — this corresponds to the “5” size.

Right now '201 and '22 share the same depth metric, which may be the cause of all the troubles.

[RuixiZhang42]

[norbusan]

Just searching around found that https://tex.stackexchange.com/questions/191632/latex-extensible-delimiters-definitions I need to read in detail, but being very busy till next week Wednesday I will not have a chance to look into it for now.

[yannis1962]

dear all, thank you very much for your interest in yhmath. I confess I haven't looked into its METAFONT code ever since 1996, I'm not even sure whether I can display METAFONT smoke mode on my current machine. If you have change suggestions please do them and send me just a copy of the new files so that I can test them (by typesetting the "manual"). But I really don't have the time to delve into the code, detect the bugs and correct them. Thanks in advance, Yannis

[RuixiZhang42]

Here is a somewhat thorough comparison between cmex10.pl and the first-half of yhcmex10.vpl. I found the cmex10.pl property list source at ftp://ctan.tug.org/tex-archive/fonts/psfonts/psnfss-source/mathpple/cmex10.pl

1. Octal 0–13, 16, 17, 160 (15 slots):
   (CHARDP R 1.135568) should be (CHARDP R 1.160013)
2. Octal 110, 122 (2 slots):
   (CHARDP R 1.135568) should be (CHARDP R 1.111122)
3. Octal 14, 15, 66, 67, 77, 102, 103, 165, 167, 170, 171, 176, 177 (13 slots):
   (CHARDP R 0.580007) should be (CHARDP R 0.600006)
4. Octal 166 (1 slot):
   (CHARDP R 0.580007) should be (CHARDP R 0.560007)
5. Octal 20, 21, 56–65, 100, 101, 104, 105, 150–157, 161 (23 slots):
   (CHARDP R 1.780019) should be (CHARDP R 1.760019)
6. Octal 74, 75, 164 (3 slots):
   (CHARDP R 1.780019) should be (CHARDP R 1.800018)
7. Octal 22–37, 162 (15 slots):
   (CHARDP R 2.250579) should be (CHARDP R 2.360025)
8. Octal 111, 132 (2 slots):
   (CHARDP R 2.250579) should be (CHARDP R 2.222246)
9. Octal 70–73 (4 slots):
   (CHARDP R 0.900011) should be (CHARDP R 0.900009)
10. Octal 106, 112, 114, 116, 120, 121, 123–127, 140 (12 slots):
    (CHARDP R 0.900011) should be (CHARDP R 1.000013)
11. Octal 107, 113, 115, 117, 130, 131, 133–137, 141 (12 slots):
    (CHARDP R 1.490013) should be (CHARDP R 1.500012)

The above list contains 102 slots that need to be fixed in the first 128 slots. If the correct metrics are used, then we should remove the 32 lines containing MOVEDOWN.

Again, I’m leaning towards a metric issue — I don’t think there are bugs in yrcmex10. Instead, the merged yhcmex10 seems to contain inaccurate metrics.

[RuixiZhang42]

And here is my proposed metrics for the second-half (the remaining 128 slots):

1 and 2 are major, 3–6 are minor and 7–10 need no changes at all.

1. Octal 200, 212, 224, 227, 232, 235, 240, 243, 246, 251, 254, 266, 300, 304, 310 (15 slots):
   (CHARDP R 1.490013) should be (CHARDP R 1.460016)
   These are the 1.5em’s.
2. Octal 201, 213, 225, 230, 233, 236, 241, 244, 247, 252, 255, 267, 301, 305, 311 (15 slots):
   (CHARDP R 2.250579) should be (CHARDP R 2.060022)
   These are the 2.1em’s.
3. Octal 204, 216, 260, 272, 314 (5 slots):
   (CHARDP R 3.560038) should be (CHARDP R 3.560037)
   These are the 3.6em’s.
4. Octal 205, 217, 261, 273, 315 (5 slots):
   (CHARDP R 4.160044) should be (CHARDP R 4.160043)
   These are the 4.2em’s.
5. Octal 206, 220, 262, 274, 316 (5 slots):
   (CHARDP R 4.76005) should be (CHARDP R 4.760049)
   These are the 4.8em’s.
6. Octal 207, 221, 263, 275, 317 (5 slots):
   (CHARDP R 5.360056) should be (CHARDP R 5.3600555)
   These are the 5.4em’s.
7. The 2.7em’s depths are all set at 2.660028 correctly (15 slots, no need to change).
8. The 3.0em’s depths are all set at 2.9600315 correctly (7 slots, no need to change).
9. The 6.0em’s depths are all set at 5.960062 correctly (5 slots, no need to change).
10. The 6.6em’s depths are all set at 6.560068 correctly (5 slots, no need to change).

The above list contains 82 slots (50 of which need adjustments). The rest 46 slots are wide accents (10 \widehat, 10 \widetilde, 13 \widetriangle and 13 \wideparen), which seem to be bug-free.

[RuixiZhang42]

I have prepared the new vplfile with the correct font metrics: yhmath-new-vplfile.txt

This can be used as direct replacement from line 1937 to 4564 in the yhmath.dtx file. It contains precisely 152 (=102+50) additions of the new depth metrics and 184 (=102+50+32) deletions of the old ones.

[norbusan]

Thanks a lot for your work @RuixiZhang42
I will put the stuff into an experimental branch and rebuild everything, then send out tests to @yannis1962 and others.
But please, all after tomorrow ;-)

[norbusan]

Ok, I did it already: The devel branch now contains the changes you mentioned, with updated .tfm, .vf, and .pdf of the documentation.

[RuixiZhang42]

@norbusan No worries. There is no reason to rush, considered the scope of this project, ;-)

I had a few minutes to test my examples, here are the old versus new metrics results:

• Green circles: These are fixed due to the removal of MOVEDOWN.
• Purple circles: These are shifted down a little, but still not exactly centered, so fixed half-way (?).
• Orange circles: These are strange, since the radical is clearly fixed (yeah!!) but the floor is not.
  But if I changed 2.4em to 2.5em, then \bigg showed up! Still not fixed though.
• Red circles: The \big (smallest extensible) size now jumps to the next large intermediate one.
  But if I changed 1.2em to 1.15em, then \big showed up (except for radical)! But the vertical positions were off.

The conclusion I can draw is that the new metrics only fixes some of the problem…

[RuixiZhang42]

Hmmm… I took a look at yhbigdel.mf (mffilec) in the development branch. Lines 694 through 1333 are supposed to be exactly the same as bigdel.mf right?

% yhmath.dtx
L1209: --z2r---z1r--z1l---z2l--subpath (t,0) of\\(z3l{z9-z3}..z5r)
L1228: --z2r---z1r--z1l---z2l--subpath (t,0) of\\(z3r{z9-z3}..z5r)
L1232: "Extensible vertical arrow--extension module";
L1281: "Extensible double vertical arrow--extension module";

% versus bigdel.mf, respectively
--z1r--z1l--subpath (t,0) of\\(z3l{z9-z3}..z5r)
--z1r--z1l--subpath (t,0) of\\(z3r{z9-z3}..z5r)
cmchar "Extensible vertical arrow--extension module";
cmchar "Extensible double vertical arrow--extension module";

I’m suspecting yrcmex10.tfm now, but have no idea how to convert it into property list… I can’t find online tutorial on how to use tftopl in Windows with MiKTeX… :(

[norbusan]

Thanks for your analysis, indeed this is strange. Concerning tftopl, doesn't MikTeX provide this binary? You would call tftopl.exe yrcmex10.tfm > yrcmex10.pl to get it. Here is what I got:
yrcmex10.pl.txt

[RuixiZhang42]

@norbusan I can confirm that the metrics in yrcmex10.tfm/yrcmex10.pl are incorrect. Here are some of the evidence:

The metrics in yrcmex10.pl are quite a mess. Here is my attempted fix: yrcmex10-new.pl.txt
I made the changes so that yrcmex10-new.pl could match yhmath-new-vplfile exactly.

[norbusan]

@RuixiZhang42 Unfortunately this is not the way to go with the pl. The tfm is generated from the metafont source, so one would need to make changes in the respective .mf files. FOr example, you changed char0 depth:

 (CHARACTER O 0
    (CHARWD R 0.458336)
    (CHARHT R 0.039999)
-   (CHARDP R 1.030011)
+   (CHARDP R 1.160013)
    (NEXTLARGER O 200)
    )

but this value comes from here yhbigdel.mf:

cmchar "\big left parenthesis";
beginchar(oct"000",7u#,rule_thickness#,2dh#-rule_thickness#);
adjust_fit(1.5u#,-.25u#); left_paren(hair,stem); endchar;

This is the very same definition as in the original bigdel.mf of the CM fonts. So I am a bit surprised. Where do your changed values come from? From cmex10.pl? The code generating char000 is exactly the same in cmex10 and yrcmex10.

I checked the generating mf files, cmex10.mf and yrcmex10.mf, only difference is font identifier and the calling of the driver file (yh)mathex.mf

Then I compared mathex.mf to yhmathex.mf and again the only difference is in the calling of (yh)bigdel.mf and (yh)bigacc.mf.

Checking the yhbigdel.mf against bigdel.mf I don't see any change in char0, so I am surprised about where you get these new values from?

[norbusan]

This is indeed very cryptic .. generating the cmex10.tfm which has NO changes with respect to char0, I get differences between the generated pl files:

--- cmex10.pl   2019-03-07 09:30:01.263513678 +0900
+++ yrcmex10.pl 2019-03-07 09:26:23.806362300 +0900
@@ -1,7 +1,7 @@
 (DESIGNSIZE R 10.0)
 (COMMENT DESIGNSIZE IS IN POINTS)
 (COMMENT OTHER SIZES ARE MULTIPLES OF DESIGNSIZE)
-(CHECKSUM O 37254272422)
+(CHECKSUM O 16003002643)
 (FONTDIMEN
    (SLANT R 0.0)
    (SPACE R 0.0)
@@ -20,74 +20,74 @@
 (CHARACTER O 0
    (CHARWD R 0.458336)
    (CHARHT R 0.039999)
-   (CHARDP R 1.160013)
-   (NEXTLARGER O 20)
+   (CHARDP R 1.030011)
+   (NEXTLARGER O 200)
    )
...

And I have NO idea whatsoever where this might come from ...

[norbusan]

Ok, this is getting strange ... I removed every other change and only add the following code in bigdel.mf at the end:

cmchar "\big left parenthesis";
beginchar(oct"200",8u#,rule_thickness#,2.5dh#-rule_thickness#);
adjust_fit(1.75u#,-.25u#); left_paren(hair,stem); endchar;

cmchar "\big left parenthesis";
beginchar(oct"201",10u#,rule_thickness#,3.5dh#-rule_thickness#);
adjust_fit(2.25u#,-.25u#); left_paren(hair,stem); endchar;


cmchar "\big left parenthesis";
beginchar(oct"202",12u#,rule_thickness#,4.5dh#-rule_thickness#);
adjust_fit(2.75u#,-.25u#); left_paren(hair,stem); endchar;

cmchar "\big left parenthesis";
beginchar(oct"203",13u#,rule_thickness#,5dh#-rule_thickness#);
adjust_fit(3u#,-.25u#); left_paren(hair,stem); endchar;


cmchar "\big left parenthesis";
beginchar(oct"204",15u#,rule_thickness#,6dh#-rule_thickness#);
adjust_fit(3.5u#,-.25u#); left_paren(hair,stem); endchar;

cmchar "\big left parenthesis";
beginchar(oct"205",17u#,rule_thickness#,7dh#-rule_thickness#);
adjust_fit(4u#,-.25u#); left_paren(hair,stem); endchar;

cmchar "\big left parenthesis";
beginchar(oct"206",19u#,rule_thickness#,8dh#-rule_thickness#);
adjust_fit(4.5u#,-.25u#); left_paren(hair,stem); endchar;

This should not change the size of other chars, but it does ...

[norbusan]

https://tex.stackexchange.com/questions/478127/metafont-character-dimension-of-unchanged-glyphs-change-when-adding-new-glyphs

[RuixiZhang42]

@norbusan

Unfortunately this is not the way to go with the pl. The tfm is generated from the metafont source, so one would need to make changes in the respective .mf files.

Yes, this is what I’ve suspected — that the TFM is directly generated from the MF.

[…] where you get these new values from?

As your discovered in later comments, the “correct” dimensions are taken from cmex10.pl (the unaltered cmex10.tfm source) for the first 128 characters. For the next 128 characters, I just interpolated the depth (and this is how I came up with the new VPL file).

This is really bizarre… :( But I hope my “evidence” at least shed some light:

• If I say \delimiterfactor=910 %, then size-5 delimiter comes up.
• If I say \delimiterfactor=890 %, then size-1 delimiter is correct.

Side note: My proposed VPL file and yrcmex10-new.pl could serve as target dimensions; that is, the generated metrics should come close to the ones in my proposal.

[norbusan]

Yeah, I think your experiments are extremely valuable, but before doing any changes I need to know why the depths change in the glyphs, so that I understand the reason for all this ...

[norbusan]

Here we go, the answer is that mf only allows up to max 15 different depth values: https://tex.stackexchange.com/a/478144/10829

This is an interesting question, and one probably needs to think about how this can be circumvented.

[RuixiZhang42]

Can we simply remove the first 128 characters from yrcmex10? After all, yhcmex10 is built by merging the same 128 characters from cmex10 followed by the next 128 new characters from yrcmex10. Would this cope the hard limit of 15?

[norbusan]

I guess so, since the yhcmex10 can be build from the cmex10 and minimal yhrcmex10. I am not sure whether the limitation on depth applies also to tfm files generated from vpl.

And one would need to make sure that the vpl contains the correct NEXTCHAR calls that match the charlist in the metafont source.

[norbusan]

Ahhh, it seems it won't work. Reading the explanation in the tex.sx answer it seems a format restriction in the tfm file format, thus also those generated from vpl will have these restrictions :-(

[norbusan]

Also, reading the output of the mktextfm call, I now see

(some chardp values had to be adjusted by as much as 0.24446pt)

:-(

[RuixiZhang42]

Ouch! Well, I guess the only option left is to reduce the number of glyphs… It’s a trade-off between wrong dimensions and fewer glyphs.

I’d suggest to remove all intermediate sizes: 1.5em, 2.1em and 2.7em — they are not accessible via \big and friends (which is the normal usage), but only via \left/\right (which is discouraged by most people).

I’d also suggest to remove the largest size: 6.6em — if necessary. See, every row of a matrix is inserted with a strut by default, which means it’s about 1.2 times high as the font size. So a 5-row pmatrix would use 5×1.2=6em parentheses, while a 6-row pmatrix would use 6×1.2=7.2em parentheses. So going from 5-row to 6-row we would have straight parentheses anyway. In this regard, the 6.6em sizes are not usual as well.

This saves 3 (or 4 if 6.6em’s are removed) depths.

[zauguin]

Instead of deleting some glyphs, you could try to exploit the height: TeX always uses height+depth for the delimiter size, so you could get additional size variantions by using different heights. (yrcmex10 only uses 5 of it's 15 possible height values right now.)

This would break with the TeX tradition of using rule_thickness as height of all extensible characters, but as long as noone tries to use these as radicals that should not have any effect.

[RuixiZhang42]

@zauguin But the radicals are in there :( Surely, this could work for the parentheses, angle brackets, slashes, etc. But the radicals must sink below the baseline… So that many depths are necessary if you want to keep all glyphs.

BTW, the combined virtual property list yhcmex10.vpl already requests 14 different heights…

[norbusan]

I suggest something different: what about making one font only containing the cnex + yhcmex delimiters without the other cmex glyphs, so that we can do the charlist stuff.
Then we use in the .fd definition two different fonts for defining the math glyphs. We don't need each and every math glyph coming from the same font in latex, loading both shouldn't be a problem.

[norbusan]

Actually, looking at the current code I don't see a need to include the bigop.mf at all, since the yhmath.sty does not use it. But this unfortunately does not suffice.

So we would need separate fonts for separate delimiters, allocate two families, and use them. Should be doable.

[RuixiZhang42]

Splitting up the font is barely enough. Let’s do the count:

• Parentheses 15 depths needed. 1.2(0.3)3.0(0.6)6.6, that’s 13 required, plus 1 for the top/bottom piece, 1 for the middle.
• Angle brackets 13 depths needed.
• Radicals 16 depths needed. 13 required, plus 1 for the bottom piece, 1 for the vertical line, 1 for the top corner. Though the vertical line (oct 165) has the same total height as the corner (oct 166), so maybe we could use @zauguin’s idea to cut the depths here down to 15.

[RuixiZhang42]

Okay, I think I’ve done it:

• Oct 14 (\vert), 15 (\Vert), 77 and 167–177 (\arrowvert, \Arrowvert, \underbrace, \overbrace) removed.
• Oct 106–141 (big operators) removed.
• Still cannot be fully fixed, so I proceed to aggressively remove Oct 70–76 (\{, \}, \lmoustache, \rmoustache), because they introduce 2 more depths. But now they cannot grow after size-7, of course.

Voilà!

If we just remove those 3 intermediate sizes, then we’d save 3 depths, which can then be given to Oct 70–76, problem solved…

[RuixiZhang42]

@norbusan I’m pleased to announce that I have combined both your suggestion (removing big operators) and @zauguin’s suggestion (exploiting heights). No need to remove further glyphs (yeah!!!).

My strategies are:

• Removing big operators Oct 106–141.
• Shifting Oct 14, 15, 60–67, 74, 75, 77–103, 164, 165, 167–171, 176, 177 up by 0.4pt, so that their depths can be shared with those of the radicals;
• Shifting Oct 70–73 and 76 up by their total heights, so that they sit above the baseline. This only takes 2 heights space.

These would be the minimal changes required and I’m very confident that this could work.

• mffileb-RZ.txt
• mffilec-RZ.txt
• vplfile-RZ.txt

The reference I’m using is Technical Report on Math Font Encoding by Justin Ziegler. In particular, Appendix C.7.

[yannis1962]

How about making a series of fonts, where each font has 256 different sizes of a given symbol? (one font for the left parenthesis, one for the right, etc.) Wouldn't that be the ideal solution? We would get a very smooth between sizes and would be able to have much bigger symbols. Cheers Yannis

Le 9 mars 2019 à 19:49, Ruixi Zhang ***@***.*** ***@***.***>> a écrit : @norbusan <https://github.com/norbusan> I’m pleased to announce that I have combined both your suggestion (removing big operators) and @zauguin <https://github.com/zauguin>’s suggestion (exploiting heights). No need to remove further glyphs (yeah!!!). My strategies are: Removing big operators Oct 106–141. Shifting Oct 14, 15, 60–67, 74, 75, 77–103, 164, 165, 167–171, 176, 177 up by 0.4pt, so that their depths can be shared with those of the radicals; Shifting Oct 70–73 and 76 up by their total heights, so that they sit above the baseline. This only takes 2 heights space. These would be the minimal changes required and I’m very confident that this could work. mffileb-RZ.txt <https://github.com/TeX-Live/yhmath/files/2948741/mffileb-RZ.txt> mffilec-RZ.txt <https://github.com/TeX-Live/yhmath/files/2948743/mffilec-RZ.txt> vplfile-RZ.txt <https://github.com/TeX-Live/yhmath/files/2948744/vplfile-RZ.txt> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAtxffxLYTDfckDvt7KNWGRcZepDgiqYks5vVAIdgaJpZM4bSUo0>.

<http://www.imt-atlantique.fr/> Yannis HARALAMBOUS Professor Computer Science Department UMR CNRS 6285 Lab-STICC <http://perso.telecom-bretagne.eu/yannisharalambous/> <https://twitter.com/y_haralambous> <https://www.linkedin.com/in/yannis-haralambous-5529073?trk=hp-identity-name>Technopôle Brest-Iroise CS 83818 29238 Brest Cedex 3, France Une école de l'IMT <http://www.imt.fr/> Be sure to never split an infinitive. Prepositions are bad to end sentences with. (Ivan Sag & Thomas Wasow)

[zauguin]

@yannis1962 That doesn't solve the problem: There would still be only 15 different heights/depths, so it would not allow much more variants than the current font. For non-radicals you could use some height tricks, but especially for radicals this would give you only a minor benefit. Also then every character would need a TeX mathfont and TeX only allows 16 math fonts to be used at once with quite some of them already used for other stuff.

[RuixiZhang42]

Well, the good news is that after shifting up, running miktex-mf.exe on mffilec-RZ (aka yrcmex10.mf), I saw zero messages like some chardp values had to be adjusted.

The other good news is that all “one-piece” size variants are now fully functional.

… and the bad news is that TeX does not like how I shift up the extensible pieces:

Any ideas, @zauguin ?

[RuixiZhang42]

Wait… yrcmex10 (from my humble mffilec-RZ) is now fully functional. Its METAFONT source contains all glyphs from cmex10 (expect for big operators). If we use the old yrcmex10, then we already know that we cannot merge it with cmex10 (not enough room for more depths, which means yhcmex10 is obsolete). If we use the new yrcmex10, then we just declare one more family yrcmex10 for the delimiters/radicals and take big operators from cmex10.

@norbusan Could you rebuild yhcmex.pfb so that it contains the cmex10 delimiters? AFAICT, my revised yrcmex10 is fine. If I change all (SELECTFONT D 0) into (SELECTFONT D 1) in my vplfile-RZ file (which makes it identical to yrcmex10) along with the revised shifted metrics, then I’d expect normal behavior from the extensible pieces.

[norbusan]

@RuixiZhang42 Thanks a lot for your work, I tried with your updates mf/vpl files and the metafont font instead of the type1, but there is an error in the extensible parenthesis, see the following image. THere is a gap:

[norbusan]

The problematic case with the extensible brace - did it happen with type1 font of metafont? I cannot reproduce it here.

BTW, your changes are in the devel branch if you want to hack further. If you have a github account, I can add you to this project so that you can make changes yourself.

[RuixiZhang42]

The problematic case with the extensible brace - did it happen with type1 font of metafont? I cannot reproduce it here.

Yes, for type1. I’m self-taught a whole new language so I can be wrong… I couldn’t figure out how to build a .pfb file so I only used my updates on yrcmex10.tfm, yhcmex10.vf and yhcmex10.tfm, and the extensible braces were all over the place. I’m glad that your mf test is fine.

[T]here is an error in the extensible parenthesis […] T[h]ere is a gap […]

This also happens with square brackets, floors, ceilings after size-7 and radicals after size-13. Gaps appear to be present for all extensible sizes.

My theory is on the instruction

(SELECTFONT D 0)

which takes glyphs from cmex10. However, since I’ve shifted up all the extensible modules, the new metrics are not compatible with the old ones in cmex10 (glyphs from cmex10 are lower, hence the gap near the top, perhaps).

Could you test whether replacing all (SELECTFONT D 0) with (SELECTFONT D 1) would work? I did this a few days ago, but got blanks since the first 128 slots in type1 font were empty. I was hoping that a mf version would work.

[norbusan]

Just a quick question @RuixiZhang42 I was reading again the changes of the glyphs, like

 cmchar "Extensible left parenthesis---extension module";
-beginchar(oct"102",12u#,0,dh#);
+beginchar(oct"102",12u#,rule_thickness#,dh#-rule_thickness#); %%%% was ,0,dh#)
 adjust_fit(4u#,-.25u#); pickup fine.nib;

But ... don't we have to also adjust the actual drawing if we shift the sizes? I mean, we draw on a certain area but the used clip window is shifted upward. Isn't that the reason that the glyphs have now the open gaps?

And, shouldn't also the appearance (vertical position) of the other glyphs (not expandable ones) be slightly different due to the shift?

[norbusan]

My theory is correct, I changed to 10rule_thickness# shift for "(", and this is what I got:

So no, that is not what we can do easily without adjusting the actual painting area, too.

[norbusan]

PS: this was with the MF font (pk glyphs), not the pfb, so it is irrelevant from the pfb/type1 font!

[RuixiZhang42]

Hmm… I’m definitely missing something here. The following is taken from the Technical Report on Math Font Encoding by Justin Ziegler:

I might have missed some y-coordinates.

[ivankokan]

Any progress?

[norbusan]

Not really