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
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
|
show 1 more comment
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
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, maybeadjust_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 simpleendinput.
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 usedmaketextfm --destdir ...
and I don't remember seeing a warning ...
– norbert
1 hour ago
|
show 1 more comment
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
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
metafont
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, maybeadjust_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 simpleendinput.
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 usedmaketextfm --destdir ...
and I don't remember seeing a warning ...
– norbert
1 hour ago
|
show 1 more comment
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, maybeadjust_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 simpleendinput.
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 usedmaketextfm --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
|
show 1 more comment
1 Answer
1
active
oldest
votes
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.
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 totfm
files, esp. can I use avpl
file that has more different depth values than 15, and generate avf
andtfm
from it?
– norbert
1 hour ago
Ahh, answering my own question: it is pertinent totfm
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
add a comment |
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
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
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.
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 totfm
files, esp. can I use avpl
file that has more different depth values than 15, and generate avf
andtfm
from it?
– norbert
1 hour ago
Ahh, answering my own question: it is pertinent totfm
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
add a comment |
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.
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 totfm
files, esp. can I use avpl
file that has more different depth values than 15, and generate avf
andtfm
from it?
– norbert
1 hour ago
Ahh, answering my own question: it is pertinent totfm
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
add a comment |
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.
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.
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 totfm
files, esp. can I use avpl
file that has more different depth values than 15, and generate avf
andtfm
from it?
– norbert
1 hour ago
Ahh, answering my own question: it is pertinent totfm
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
add a comment |
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 totfm
files, esp. can I use avpl
file that has more different depth values than 15, and generate avf
andtfm
from it?
– norbert
1 hour ago
Ahh, answering my own question: it is pertinent totfm
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
add a comment |
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
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