-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
French SI Brochure feedback from BIPM (pages 21-40) #41
Comments
|
For rb, see #40 |
I understand that this is suposed to be handled automatically (and not by markup).
All three fixed.
This is a rendering issue. Not fixable by markup.
Fixed
Ok, I believe that
Fixed.
This is not fixable by markup. @opoudjis?
This a rendering isssue. Not fixable by markup.
I can change attributes of the table in order to indicate that certain columns must be wider than others (e.g.
Not fixable by markup
White space removed. (See comment above.)
Fixed.
Not fixable by markup (unless I pasted the literal symbol). @ronaldtse ?
All three fixed.
I changed the image file.
Fixed. Line breaks were inserted manually.
Not sure what to do here. I changed "149" by "140", but should I put a cross-reference here? If so, this cross reference must link to an external document (the English version of Brochure). @opoudjis?
White space removed.
Not fixable by markup (unless I pasted the literal symbol).
White space removed.
Fixed.
Not fixable by markup (unless I pasted the literal symbol).
Fixed "rayon r" part. But "omega in italics" is not fixable by markup.
All two fixed. |
The fixes are in PR #45 |
Thanks @Intelligent2013! I take your suggestion. Changes applied. |
That's a nightmare scenario, but we do provide for it under collections. The problem is that this is going to force a massive unwelcome change to how we process crossreferences between documents. To reference another document in a collection, use:
in the bibliography, and
I think this will break. Do it anyway. We will have to deal with it when it does. |
@Intelligent2013 bringing you in here. The XML here is:
Now, the MathML spec explicitly says that Greek constants like pi must be marked up as mi, not mn: https://www.w3.org/TR/MathML3/chapter3.html#presm.mi . The problem is, MathJax, and clearly Euclid, are blanket rendering anything in mi as italics, and Greek lowercase letters are not italicised in maths. (Practice varies for capital Greek letters, and MathJax treats it as an amsmath config option: https://tex.stackexchange.com/questions/87238/greek-letters-in-italic-in-math-equation.) As https://tex.stackexchange.com/a/440589 indicates, this is a local preference:
And sure enough: https://tex.stackexchange.com/questions/159973/french-math-style-with-default-font
This is a rendering option in TeX. We need to find out if this is a rendering option in jEuclid and in MathJax. This will NOT be addressed by manually injecting italics or CSS in MathML. We might get away with that, just, in Word; we will not get away with that in PDF. The BIPM HTML, risibly, used GIFs for Greek letters. No, I am not making this up: https://www.bipm.org/fr/CGPM/db/26/1/ . They therefore have no ability whatsoever to provide any guidance for the proper HTML rendering of MathML, and little authority to demand French rendering. |
Flabbergastingly, the MathJax TeX font, which is the default font MathJax uses, has no support for upright lowercase Greek characters at all; mathjax/MathJax#2123: a non-italic pi is impossible within MathJax even with the "mathvariant" override attribute (which I really do not want to use; cf. mathjax/MathJax#592). We would have to shift to STIX-Web font to display any upright Greek fonts at all. |
|
I've checked jEuclid set mathvariant style for if (StringUtil.countDisplayableCharacters(this.getText()) == 1) {
this.setDefaultMathAttribute(
AbstractJEuclidElement.ATTR_MATHVARIANT, "italic");
} else {
this.setDefaultMathAttribute(
AbstractJEuclidElement.ATTR_MATHVARIANT, "normal");
} Regarding https://www.w3.org/TR/MathML3/chapter3.html#presm.mi, the default value of If we append zero-width space after pi inside <stem type="MathML"><math xmlns="http://www.w3.org/1998/Math/MathML"><mn>2</mn><mi>π</mi><mtext> rad</mtext></math></stem> |
Ok. This becomes new ticket: metanorma/metanorma-standoc#367 |
Regarding issue:
The reason of misaligment between I see only one solution - isolating I,.e. from:
to
|
Um... ... That solution does such violence to the MathML, I would much rather we refuse to implement it at all. Whatever @ronaldtse has planned for UnitsML, it will decidedly not permit this kind of rearrangement of text: units will be treated as semantically meaningful elements. The At any rate: https://en.wikipedia.org/wiki/International_System_of_Units
The superscript on the K is going to be misaligned no matter what you do, because the K is taller than the m. So this solution won't scale even if it were semantically permissible. |
This could be addressed by adding an So this does work:
But... how do I know what the right point measure for superscripting should be? We really should not be being forced to do this amount of fine tuning of rendering. And w3c/mathml#27 indicates that this functionality will be removed from MathML Core in the future. ... The real issue here, actually, is simple. BIPM until now have been getting Word superscripting as how units are rendered, which means a fixed height for all superscripts. They will simply not be getting that from us: if there is to be any machine readable units, what they will be getting is what MathML gives them. And what MathML gives them is uneven exponents. My recommendation: that they resign themselves to it. |
@opoudjis , problem is, there is no bibliography section in original document. I would need to create one. Should I do so? |
Do so for now. I will have to implement code to remove it from ultimate rendering, and this is an issue for ISO 10303 as well, but the reference needs to be in there before we can process the reference at all. |
Changes pushed to master branch directly. |
metanorma/metanorma#146 will address removing (hiding) those internal bibliographic entries. |
Based on the latest PDF provided by @opoudjis: si-brochure-fr(12-01).pdf These are the issues that don't fulfill with BIPM requirements yet.
|
Fixed. I've increased a bit the height of exponents.
I can't change column width for concrete table. Columns width set automatically depends on longest word in cell. For this table:
As workaround solution you can try to split long stems in last column into two stems.
This page number shows only in two-languages PDF. In French only it doesn't show. |
See #40 (comment)
Metanorma is implementing the French mathematical typesetting rule, that uppercase variables are upright. Where that is ignored, you need to introduce explicit font styling: Note that this won't work until metanorma/metanorma-standoc#386 is merged in; it isn't yet, because of a bug somewhere else in the stack. |
One remaining issue in this thread:
|
@opoudjis it seems that is not possible to increase the column width in tables by using AsciiDoc attributes like: Is there another way to address this issue? |
There is a ticket requesting that I introduce column width: metanorma/metanorma-standoc#251 There is no other way to address it, but that would. I don't like doing it, being a purist, but I don't think I can avoid this in the long term. WIll realise that ticket. |
Since the new ticket is opened to address this issue, I'm closing this one. I'll create a new ticket for these remaining issues which require more time to be solved, so that we can track what's left for the BIPM. |
The text was updated successfully, but these errors were encountered: