MetaFont: character dimension of unchanged glyphs change when adding new glyphs?Sample Metafont source for...

Effect of "wrong" driver with slightly long RS-485 stubs

In the world of The Matrix, what is "popping"?

Called into a meeting and told we are being made redundant (laid off) and "not to share outside". Can I tell my partner?

Why are special aircraft used for the carriers in the United States Navy?

How do you write a macro that takes arguments containing paragraphs?

Split a number into equal parts given the number of parts

How will Occam's Razor principle work in Machine learning

« Rendre » et « render » (the meaning)

Can an earth elemental drown/bury its opponent underground using earth glide?

The need of reserving one's ability in job interviews

Why won't the strings command stop?

How to draw tikz paths composed only of horizontal, vertical and diagonal segments?

Convert an array of objects to array of the objects' values

Plagiarism of code by other PhD student

What is the meaning of "producing negative zeroes" in a system that doesn't support it?

Can I solder 12/2 Romex to extend wire 5 ft?

Are small insurances worth it

How can friction do no work in case of pure rolling?

Faulty RAID1 disk now shows as foreign

3.5% Interest Student Loan or use all of my savings on Tuition?

How does insurance birth control work?

Giving a talk in my old university, how prominently should I tell students my salary?

Can a Tiny Servant be used as a messenger?

Is there a math equivalent to the conditional ternary operator?



MetaFont: character dimension of unchanged glyphs change when adding new glyphs?


Sample Metafont source for one characterFinding METAFONT sources of a specific characterchange default metafont's mode/resolution (as when called directly from pdflatex)metafont crashes when using showitWhat to do to make Metafont stop emitting “! Emergency stop.” when i type relax













5















I have a very strange effect while debugging yhmath math fonts items. I am generating cmex10.tfm from cmex10.mf, and convert the tfm to pl file.



Then I rename only rename the driver file to yrcmex10.mf, and add the following new glyph definitions in bigdel.mf, without changing anything in the rest of the files:



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;


So the only diff between the cmex10 font and yrcmex10 font is the addition of the above characters.



Converting both tfm to pl, and making a diff I see changes in unrelated glpyphs, in particular the DP parameter changes:



--- cmex10.pl   2019-03-07 09:30:01.263513678 +0900
+++ yrcmex10.pl 2019-03-07 09:52:25.578670436 +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 35311171576)
(FONTDIMEN
(SLANT R 0.0)
(SPACE R 0.0)
@@ -20,85 +20,85 @@
(CHARACTER O 0
(CHARWD R 0.458336)
(CHARHT R 0.039999)
- (CHARDP R 1.160013)
+ (CHARDP R 1.135567)
(NEXTLARGER O 20)
)
(CHARACTER O 1
(CHARWD R 0.458336)
(CHARHT R 0.039999)
- (CHARDP R 1.160013)
+ (CHARDP R 1.135567)
(NEXTLARGER O 21)
)
...


This is very surprising, I would have guessed that the glyph dimensions of other non-changed glphs do not change. Furthermore, this changes become bigger the more additional glyphs I add.



Anyone having an explanation for this?










share|improve this question























  • Just to check: as you made two changes (renamed and added glyphs), can you double-check that simply renaming doesn't cause any changes? It would be crazy if that were the case, but still good to rule it out first, just in case. :-) Beyond that, I imagine one of the statements, maybe adjust_fit, has some side-effects (but saying so is practically only an restatement of the question, not an explanation).

    – ShreevatsaR
    14 hours ago






  • 1





    Yes, that I checked. Renaming only without adding the above code does not changes anything. A simple endinput. before the added code also suffices to get the original metrics.

    – norbert
    11 hours ago











  • did you get a warning about lengths changing, there are a fixed number of distinct lengths in a tfm file to bit-pack the information

    – David Carlisle
    7 hours ago











  • ah so you did get the warning:-)

    – David Carlisle
    2 hours ago











  • Actually not that I remember, but I will check ... I used maketextfm --destdir ... and I don't remember seeing a warning ...

    – norbert
    1 hour ago
















5















I have a very strange effect while debugging yhmath math fonts items. I am generating cmex10.tfm from cmex10.mf, and convert the tfm to pl file.



Then I rename only rename the driver file to yrcmex10.mf, and add the following new glyph definitions in bigdel.mf, without changing anything in the rest of the files:



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;


So the only diff between the cmex10 font and yrcmex10 font is the addition of the above characters.



Converting both tfm to pl, and making a diff I see changes in unrelated glpyphs, in particular the DP parameter changes:



--- cmex10.pl   2019-03-07 09:30:01.263513678 +0900
+++ yrcmex10.pl 2019-03-07 09:52:25.578670436 +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 35311171576)
(FONTDIMEN
(SLANT R 0.0)
(SPACE R 0.0)
@@ -20,85 +20,85 @@
(CHARACTER O 0
(CHARWD R 0.458336)
(CHARHT R 0.039999)
- (CHARDP R 1.160013)
+ (CHARDP R 1.135567)
(NEXTLARGER O 20)
)
(CHARACTER O 1
(CHARWD R 0.458336)
(CHARHT R 0.039999)
- (CHARDP R 1.160013)
+ (CHARDP R 1.135567)
(NEXTLARGER O 21)
)
...


This is very surprising, I would have guessed that the glyph dimensions of other non-changed glphs do not change. Furthermore, this changes become bigger the more additional glyphs I add.



Anyone having an explanation for this?










share|improve this question























  • Just to check: as you made two changes (renamed and added glyphs), can you double-check that simply renaming doesn't cause any changes? It would be crazy if that were the case, but still good to rule it out first, just in case. :-) Beyond that, I imagine one of the statements, maybe adjust_fit, has some side-effects (but saying so is practically only an restatement of the question, not an explanation).

    – ShreevatsaR
    14 hours ago






  • 1





    Yes, that I checked. Renaming only without adding the above code does not changes anything. A simple endinput. before the added code also suffices to get the original metrics.

    – norbert
    11 hours ago











  • did you get a warning about lengths changing, there are a fixed number of distinct lengths in a tfm file to bit-pack the information

    – David Carlisle
    7 hours ago











  • ah so you did get the warning:-)

    – David Carlisle
    2 hours ago











  • Actually not that I remember, but I will check ... I used maketextfm --destdir ... and I don't remember seeing a warning ...

    – norbert
    1 hour ago














5












5








5


1






I have a very strange effect while debugging yhmath math fonts items. I am generating cmex10.tfm from cmex10.mf, and convert the tfm to pl file.



Then I rename only rename the driver file to yrcmex10.mf, and add the following new glyph definitions in bigdel.mf, without changing anything in the rest of the files:



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;


So the only diff between the cmex10 font and yrcmex10 font is the addition of the above characters.



Converting both tfm to pl, and making a diff I see changes in unrelated glpyphs, in particular the DP parameter changes:



--- cmex10.pl   2019-03-07 09:30:01.263513678 +0900
+++ yrcmex10.pl 2019-03-07 09:52:25.578670436 +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 35311171576)
(FONTDIMEN
(SLANT R 0.0)
(SPACE R 0.0)
@@ -20,85 +20,85 @@
(CHARACTER O 0
(CHARWD R 0.458336)
(CHARHT R 0.039999)
- (CHARDP R 1.160013)
+ (CHARDP R 1.135567)
(NEXTLARGER O 20)
)
(CHARACTER O 1
(CHARWD R 0.458336)
(CHARHT R 0.039999)
- (CHARDP R 1.160013)
+ (CHARDP R 1.135567)
(NEXTLARGER O 21)
)
...


This is very surprising, I would have guessed that the glyph dimensions of other non-changed glphs do not change. Furthermore, this changes become bigger the more additional glyphs I add.



Anyone having an explanation for this?










share|improve this question














I have a very strange effect while debugging yhmath math fonts items. I am generating cmex10.tfm from cmex10.mf, and convert the tfm to pl file.



Then I rename only rename the driver file to yrcmex10.mf, and add the following new glyph definitions in bigdel.mf, without changing anything in the rest of the files:



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;


So the only diff between the cmex10 font and yrcmex10 font is the addition of the above characters.



Converting both tfm to pl, and making a diff I see changes in unrelated glpyphs, in particular the DP parameter changes:



--- cmex10.pl   2019-03-07 09:30:01.263513678 +0900
+++ yrcmex10.pl 2019-03-07 09:52:25.578670436 +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 35311171576)
(FONTDIMEN
(SLANT R 0.0)
(SPACE R 0.0)
@@ -20,85 +20,85 @@
(CHARACTER O 0
(CHARWD R 0.458336)
(CHARHT R 0.039999)
- (CHARDP R 1.160013)
+ (CHARDP R 1.135567)
(NEXTLARGER O 20)
)
(CHARACTER O 1
(CHARWD R 0.458336)
(CHARHT R 0.039999)
- (CHARDP R 1.160013)
+ (CHARDP R 1.135567)
(NEXTLARGER O 21)
)
...


This is very surprising, I would have guessed that the glyph dimensions of other non-changed glphs do not change. Furthermore, this changes become bigger the more additional glyphs I add.



Anyone having an explanation for this?







metafont






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked 14 hours ago









norbertnorbert

6,5421332




6,5421332













  • Just to check: as you made two changes (renamed and added glyphs), can you double-check that simply renaming doesn't cause any changes? It would be crazy if that were the case, but still good to rule it out first, just in case. :-) Beyond that, I imagine one of the statements, maybe adjust_fit, has some side-effects (but saying so is practically only an restatement of the question, not an explanation).

    – ShreevatsaR
    14 hours ago






  • 1





    Yes, that I checked. Renaming only without adding the above code does not changes anything. A simple endinput. before the added code also suffices to get the original metrics.

    – norbert
    11 hours ago











  • did you get a warning about lengths changing, there are a fixed number of distinct lengths in a tfm file to bit-pack the information

    – David Carlisle
    7 hours ago











  • ah so you did get the warning:-)

    – David Carlisle
    2 hours ago











  • Actually not that I remember, but I will check ... I used maketextfm --destdir ... and I don't remember seeing a warning ...

    – norbert
    1 hour ago



















  • Just to check: as you made two changes (renamed and added glyphs), can you double-check that simply renaming doesn't cause any changes? It would be crazy if that were the case, but still good to rule it out first, just in case. :-) Beyond that, I imagine one of the statements, maybe adjust_fit, has some side-effects (but saying so is practically only an restatement of the question, not an explanation).

    – ShreevatsaR
    14 hours ago






  • 1





    Yes, that I checked. Renaming only without adding the above code does not changes anything. A simple endinput. before the added code also suffices to get the original metrics.

    – norbert
    11 hours ago











  • did you get a warning about lengths changing, there are a fixed number of distinct lengths in a tfm file to bit-pack the information

    – David Carlisle
    7 hours ago











  • ah so you did get the warning:-)

    – David Carlisle
    2 hours ago











  • Actually not that I remember, but I will check ... I used maketextfm --destdir ... and I don't remember seeing a warning ...

    – norbert
    1 hour ago

















Just to check: as you made two changes (renamed and added glyphs), can you double-check that simply renaming doesn't cause any changes? It would be crazy if that were the case, but still good to rule it out first, just in case. :-) Beyond that, I imagine one of the statements, maybe adjust_fit, has some side-effects (but saying so is practically only an restatement of the question, not an explanation).

– ShreevatsaR
14 hours ago





Just to check: as you made two changes (renamed and added glyphs), can you double-check that simply renaming doesn't cause any changes? It would be crazy if that were the case, but still good to rule it out first, just in case. :-) Beyond that, I imagine one of the statements, maybe adjust_fit, has some side-effects (but saying so is practically only an restatement of the question, not an explanation).

– ShreevatsaR
14 hours ago




1




1





Yes, that I checked. Renaming only without adding the above code does not changes anything. A simple endinput. before the added code also suffices to get the original metrics.

– norbert
11 hours ago





Yes, that I checked. Renaming only without adding the above code does not changes anything. A simple endinput. before the added code also suffices to get the original metrics.

– norbert
11 hours ago













did you get a warning about lengths changing, there are a fixed number of distinct lengths in a tfm file to bit-pack the information

– David Carlisle
7 hours ago





did you get a warning about lengths changing, there are a fixed number of distinct lengths in a tfm file to bit-pack the information

– David Carlisle
7 hours ago













ah so you did get the warning:-)

– David Carlisle
2 hours ago





ah so you did get the warning:-)

– David Carlisle
2 hours ago













Actually not that I remember, but I will check ... I used maketextfm --destdir ... and I don't remember seeing a warning ...

– norbert
1 hour ago





Actually not that I remember, but I will check ... I used maketextfm --destdir ... and I don't remember seeing a warning ...

– norbert
1 hour ago










1 Answer
1






active

oldest

votes


















4














According to MetaFont, The Program:




Since it is quite common for many characters
to have the same height, depth, or italic correction, the TFM format
imposes a limit of 16 different heights, 16 different depths, and
64 different italic corrections.



Incidentally, the relation width[0]=height[0]=depth[0]=
italic[0]=0 should always hold, so that an index of zero implies a
value of zero.




So there can be at most 15 different depth values beside 0 in a single TFM file.
Now let's look at the depth values in your yrcmex10.pl:



     1     (CHARDP R 0.300003)
2 (CHARDP R 0.580007)
3 (CHARDP R 0.900009)
4 (CHARDP R 1.000013)
5 (CHARDP R 1.135567)
6 (CHARDP R 1.480014)
7 (CHARDP R 1.780019)
8 (CHARDP R 2.060022)
9 (CHARDP R 2.222246)
10 (CHARDP R 2.360025)
11 (CHARDP R 2.660028)
12 (CHARDP R 2.9600315)
13 (CHARDP R 3.560038)
14 (CHARDP R 4.160044)
15 (CHARDP R 4.76005)


(List generated using grep 'CHARDP' yrcmex10.pl|sort|uniq|nl)



So your font already contains the maximal number of distinct depths, which explains the changes:
The depth of 0 was 1.160013, but this value is not a part of the list above. So it would have to be added, but then there would be too many distinct depths. So when MetaFont read the additional characters, it realized that it could not store all the depths in the TFM file. So some values had to be rounded, and 1.135567 and 1.160013 are very close, making them ideal candidates.



This also explains why the change becomes bigger the more additional glyphs you add: If the new glyphs again have different depths, there are even more distinct depths MetaFont has to reduce to 15. This requires being more aggressive about "value unification", resulting in bigger changes.






share|improve this answer
























  • Thanks for the hint, that is very valuable!!!! Now I only need to figure out a way how to deal with this when multiple glyphs are available ... thanks again!

    – norbert
    4 hours ago











  • Hi Marcel, since you are obviously very adept, another question: Does the same restriction apply to tfm files, esp. can I use a vpl file that has more different depth values than 15, and generate a vf and tfm from it?

    – norbert
    1 hour ago











  • Ahh, answering my own question: it is pertinent to tfm files, so no way around :-(

    – norbert
    1 hour ago











  • @norbert AFAICT you would need LuaTeX to fix this, and it does not sound like a LuaTeX only solution would fit your use-case.

    – Marcel Krüger
    50 mins ago






  • 1





    BTW (as I was curious about the amount of rounding error), the change here is 0.24446pt ≈ 0.003395in (≈ 0.086mm), which though very tiny for the eye to care about, can make a difference of at least one pixel (“dot”) at resolution of 300 dpi or higher.

    – ShreevatsaR
    41 mins ago











Your Answer








StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "85"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2ftex.stackexchange.com%2fquestions%2f478127%2fmetafont-character-dimension-of-unchanged-glyphs-change-when-adding-new-glyphs%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes









4














According to MetaFont, The Program:




Since it is quite common for many characters
to have the same height, depth, or italic correction, the TFM format
imposes a limit of 16 different heights, 16 different depths, and
64 different italic corrections.



Incidentally, the relation width[0]=height[0]=depth[0]=
italic[0]=0 should always hold, so that an index of zero implies a
value of zero.




So there can be at most 15 different depth values beside 0 in a single TFM file.
Now let's look at the depth values in your yrcmex10.pl:



     1     (CHARDP R 0.300003)
2 (CHARDP R 0.580007)
3 (CHARDP R 0.900009)
4 (CHARDP R 1.000013)
5 (CHARDP R 1.135567)
6 (CHARDP R 1.480014)
7 (CHARDP R 1.780019)
8 (CHARDP R 2.060022)
9 (CHARDP R 2.222246)
10 (CHARDP R 2.360025)
11 (CHARDP R 2.660028)
12 (CHARDP R 2.9600315)
13 (CHARDP R 3.560038)
14 (CHARDP R 4.160044)
15 (CHARDP R 4.76005)


(List generated using grep 'CHARDP' yrcmex10.pl|sort|uniq|nl)



So your font already contains the maximal number of distinct depths, which explains the changes:
The depth of 0 was 1.160013, but this value is not a part of the list above. So it would have to be added, but then there would be too many distinct depths. So when MetaFont read the additional characters, it realized that it could not store all the depths in the TFM file. So some values had to be rounded, and 1.135567 and 1.160013 are very close, making them ideal candidates.



This also explains why the change becomes bigger the more additional glyphs you add: If the new glyphs again have different depths, there are even more distinct depths MetaFont has to reduce to 15. This requires being more aggressive about "value unification", resulting in bigger changes.






share|improve this answer
























  • Thanks for the hint, that is very valuable!!!! Now I only need to figure out a way how to deal with this when multiple glyphs are available ... thanks again!

    – norbert
    4 hours ago











  • Hi Marcel, since you are obviously very adept, another question: Does the same restriction apply to tfm files, esp. can I use a vpl file that has more different depth values than 15, and generate a vf and tfm from it?

    – norbert
    1 hour ago











  • Ahh, answering my own question: it is pertinent to tfm files, so no way around :-(

    – norbert
    1 hour ago











  • @norbert AFAICT you would need LuaTeX to fix this, and it does not sound like a LuaTeX only solution would fit your use-case.

    – Marcel Krüger
    50 mins ago






  • 1





    BTW (as I was curious about the amount of rounding error), the change here is 0.24446pt ≈ 0.003395in (≈ 0.086mm), which though very tiny for the eye to care about, can make a difference of at least one pixel (“dot”) at resolution of 300 dpi or higher.

    – ShreevatsaR
    41 mins ago
















4














According to MetaFont, The Program:




Since it is quite common for many characters
to have the same height, depth, or italic correction, the TFM format
imposes a limit of 16 different heights, 16 different depths, and
64 different italic corrections.



Incidentally, the relation width[0]=height[0]=depth[0]=
italic[0]=0 should always hold, so that an index of zero implies a
value of zero.




So there can be at most 15 different depth values beside 0 in a single TFM file.
Now let's look at the depth values in your yrcmex10.pl:



     1     (CHARDP R 0.300003)
2 (CHARDP R 0.580007)
3 (CHARDP R 0.900009)
4 (CHARDP R 1.000013)
5 (CHARDP R 1.135567)
6 (CHARDP R 1.480014)
7 (CHARDP R 1.780019)
8 (CHARDP R 2.060022)
9 (CHARDP R 2.222246)
10 (CHARDP R 2.360025)
11 (CHARDP R 2.660028)
12 (CHARDP R 2.9600315)
13 (CHARDP R 3.560038)
14 (CHARDP R 4.160044)
15 (CHARDP R 4.76005)


(List generated using grep 'CHARDP' yrcmex10.pl|sort|uniq|nl)



So your font already contains the maximal number of distinct depths, which explains the changes:
The depth of 0 was 1.160013, but this value is not a part of the list above. So it would have to be added, but then there would be too many distinct depths. So when MetaFont read the additional characters, it realized that it could not store all the depths in the TFM file. So some values had to be rounded, and 1.135567 and 1.160013 are very close, making them ideal candidates.



This also explains why the change becomes bigger the more additional glyphs you add: If the new glyphs again have different depths, there are even more distinct depths MetaFont has to reduce to 15. This requires being more aggressive about "value unification", resulting in bigger changes.






share|improve this answer
























  • Thanks for the hint, that is very valuable!!!! Now I only need to figure out a way how to deal with this when multiple glyphs are available ... thanks again!

    – norbert
    4 hours ago











  • Hi Marcel, since you are obviously very adept, another question: Does the same restriction apply to tfm files, esp. can I use a vpl file that has more different depth values than 15, and generate a vf and tfm from it?

    – norbert
    1 hour ago











  • Ahh, answering my own question: it is pertinent to tfm files, so no way around :-(

    – norbert
    1 hour ago











  • @norbert AFAICT you would need LuaTeX to fix this, and it does not sound like a LuaTeX only solution would fit your use-case.

    – Marcel Krüger
    50 mins ago






  • 1





    BTW (as I was curious about the amount of rounding error), the change here is 0.24446pt ≈ 0.003395in (≈ 0.086mm), which though very tiny for the eye to care about, can make a difference of at least one pixel (“dot”) at resolution of 300 dpi or higher.

    – ShreevatsaR
    41 mins ago














4












4








4







According to MetaFont, The Program:




Since it is quite common for many characters
to have the same height, depth, or italic correction, the TFM format
imposes a limit of 16 different heights, 16 different depths, and
64 different italic corrections.



Incidentally, the relation width[0]=height[0]=depth[0]=
italic[0]=0 should always hold, so that an index of zero implies a
value of zero.




So there can be at most 15 different depth values beside 0 in a single TFM file.
Now let's look at the depth values in your yrcmex10.pl:



     1     (CHARDP R 0.300003)
2 (CHARDP R 0.580007)
3 (CHARDP R 0.900009)
4 (CHARDP R 1.000013)
5 (CHARDP R 1.135567)
6 (CHARDP R 1.480014)
7 (CHARDP R 1.780019)
8 (CHARDP R 2.060022)
9 (CHARDP R 2.222246)
10 (CHARDP R 2.360025)
11 (CHARDP R 2.660028)
12 (CHARDP R 2.9600315)
13 (CHARDP R 3.560038)
14 (CHARDP R 4.160044)
15 (CHARDP R 4.76005)


(List generated using grep 'CHARDP' yrcmex10.pl|sort|uniq|nl)



So your font already contains the maximal number of distinct depths, which explains the changes:
The depth of 0 was 1.160013, but this value is not a part of the list above. So it would have to be added, but then there would be too many distinct depths. So when MetaFont read the additional characters, it realized that it could not store all the depths in the TFM file. So some values had to be rounded, and 1.135567 and 1.160013 are very close, making them ideal candidates.



This also explains why the change becomes bigger the more additional glyphs you add: If the new glyphs again have different depths, there are even more distinct depths MetaFont has to reduce to 15. This requires being more aggressive about "value unification", resulting in bigger changes.






share|improve this answer













According to MetaFont, The Program:




Since it is quite common for many characters
to have the same height, depth, or italic correction, the TFM format
imposes a limit of 16 different heights, 16 different depths, and
64 different italic corrections.



Incidentally, the relation width[0]=height[0]=depth[0]=
italic[0]=0 should always hold, so that an index of zero implies a
value of zero.




So there can be at most 15 different depth values beside 0 in a single TFM file.
Now let's look at the depth values in your yrcmex10.pl:



     1     (CHARDP R 0.300003)
2 (CHARDP R 0.580007)
3 (CHARDP R 0.900009)
4 (CHARDP R 1.000013)
5 (CHARDP R 1.135567)
6 (CHARDP R 1.480014)
7 (CHARDP R 1.780019)
8 (CHARDP R 2.060022)
9 (CHARDP R 2.222246)
10 (CHARDP R 2.360025)
11 (CHARDP R 2.660028)
12 (CHARDP R 2.9600315)
13 (CHARDP R 3.560038)
14 (CHARDP R 4.160044)
15 (CHARDP R 4.76005)


(List generated using grep 'CHARDP' yrcmex10.pl|sort|uniq|nl)



So your font already contains the maximal number of distinct depths, which explains the changes:
The depth of 0 was 1.160013, but this value is not a part of the list above. So it would have to be added, but then there would be too many distinct depths. So when MetaFont read the additional characters, it realized that it could not store all the depths in the TFM file. So some values had to be rounded, and 1.135567 and 1.160013 are very close, making them ideal candidates.



This also explains why the change becomes bigger the more additional glyphs you add: If the new glyphs again have different depths, there are even more distinct depths MetaFont has to reduce to 15. This requires being more aggressive about "value unification", resulting in bigger changes.







share|improve this answer












share|improve this answer



share|improve this answer










answered 7 hours ago









Marcel KrügerMarcel Krüger

12.2k11636




12.2k11636













  • Thanks for the hint, that is very valuable!!!! Now I only need to figure out a way how to deal with this when multiple glyphs are available ... thanks again!

    – norbert
    4 hours ago











  • Hi Marcel, since you are obviously very adept, another question: Does the same restriction apply to tfm files, esp. can I use a vpl file that has more different depth values than 15, and generate a vf and tfm from it?

    – norbert
    1 hour ago











  • Ahh, answering my own question: it is pertinent to tfm files, so no way around :-(

    – norbert
    1 hour ago











  • @norbert AFAICT you would need LuaTeX to fix this, and it does not sound like a LuaTeX only solution would fit your use-case.

    – Marcel Krüger
    50 mins ago






  • 1





    BTW (as I was curious about the amount of rounding error), the change here is 0.24446pt ≈ 0.003395in (≈ 0.086mm), which though very tiny for the eye to care about, can make a difference of at least one pixel (“dot”) at resolution of 300 dpi or higher.

    – ShreevatsaR
    41 mins ago



















  • Thanks for the hint, that is very valuable!!!! Now I only need to figure out a way how to deal with this when multiple glyphs are available ... thanks again!

    – norbert
    4 hours ago











  • Hi Marcel, since you are obviously very adept, another question: Does the same restriction apply to tfm files, esp. can I use a vpl file that has more different depth values than 15, and generate a vf and tfm from it?

    – norbert
    1 hour ago











  • Ahh, answering my own question: it is pertinent to tfm files, so no way around :-(

    – norbert
    1 hour ago











  • @norbert AFAICT you would need LuaTeX to fix this, and it does not sound like a LuaTeX only solution would fit your use-case.

    – Marcel Krüger
    50 mins ago






  • 1





    BTW (as I was curious about the amount of rounding error), the change here is 0.24446pt ≈ 0.003395in (≈ 0.086mm), which though very tiny for the eye to care about, can make a difference of at least one pixel (“dot”) at resolution of 300 dpi or higher.

    – ShreevatsaR
    41 mins ago

















Thanks for the hint, that is very valuable!!!! Now I only need to figure out a way how to deal with this when multiple glyphs are available ... thanks again!

– norbert
4 hours ago





Thanks for the hint, that is very valuable!!!! Now I only need to figure out a way how to deal with this when multiple glyphs are available ... thanks again!

– norbert
4 hours ago













Hi Marcel, since you are obviously very adept, another question: Does the same restriction apply to tfm files, esp. can I use a vpl file that has more different depth values than 15, and generate a vf and tfm from it?

– norbert
1 hour ago





Hi Marcel, since you are obviously very adept, another question: Does the same restriction apply to tfm files, esp. can I use a vpl file that has more different depth values than 15, and generate a vf and tfm from it?

– norbert
1 hour ago













Ahh, answering my own question: it is pertinent to tfm files, so no way around :-(

– norbert
1 hour ago





Ahh, answering my own question: it is pertinent to tfm files, so no way around :-(

– norbert
1 hour ago













@norbert AFAICT you would need LuaTeX to fix this, and it does not sound like a LuaTeX only solution would fit your use-case.

– Marcel Krüger
50 mins ago





@norbert AFAICT you would need LuaTeX to fix this, and it does not sound like a LuaTeX only solution would fit your use-case.

– Marcel Krüger
50 mins ago




1




1





BTW (as I was curious about the amount of rounding error), the change here is 0.24446pt ≈ 0.003395in (≈ 0.086mm), which though very tiny for the eye to care about, can make a difference of at least one pixel (“dot”) at resolution of 300 dpi or higher.

– ShreevatsaR
41 mins ago





BTW (as I was curious about the amount of rounding error), the change here is 0.24446pt ≈ 0.003395in (≈ 0.086mm), which though very tiny for the eye to care about, can make a difference of at least one pixel (“dot”) at resolution of 300 dpi or higher.

– ShreevatsaR
41 mins ago


















draft saved

draft discarded




















































Thanks for contributing an answer to TeX - LaTeX Stack Exchange!


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2ftex.stackexchange.com%2fquestions%2f478127%2fmetafont-character-dimension-of-unchanged-glyphs-change-when-adding-new-glyphs%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

Why does my Macbook overheat and use so much CPU and energy when on YouTube?Why do so many insist on using...

How to prevent page numbers from appearing on glossaries?How to remove a dot and a page number in the...

Puerta de Hutt Referencias Enlaces externos Menú de navegación15°58′00″S 5°42′00″O /...