Pedro Andres Aranda Gutierrez <[email protected]> writes:
>> What about adding the following to Font configuration for LuaLaTeX and
>> XeLaTeX:
>>
>> Remember that LaTeX requires setting 4 fonts to reliably render all
>> parts of the document: =main= (roman) font used for main text, =sans=
>> (sans serif) font often used for headings and captions, =mono=
>> (monospace) font used for code snippets and verbatim text, and =math=
>> font used in equations. If you are using non-ASCII characters in
>> main text/headings/code/equations, make sure to specify appropriate
>> fonts that can render those characters.
>>
>
> It is already there for fontspec:
>
> ~fontspec~ distinguishes between the Roman (=main=), the Sans-Serif
> (=sans=) and the Monotype (=mono=) font, and can provide fall-backs for
> character sets (for example, ~emoji~, ~han~, ~kana~, etc.) that are
> not provided by the fonts you use in your document. See
> [[#lualatex-fontspec]] for more details. Note that ~fontspec~ does
> not work with =pdflatex= compiler. For =pdflatex=, you can control
> fonts using font packages (cf. [[#pdflatex-fonts]]).
>
> We recommend using =lualatex= or =xelatex= for reliable non-Latin
> language support and using Unicode fonts that include
> the non-Latin character sets you use to simplify the configuration
> (cf. [[#nonpdflatex-fonts]]).
Reading the existing paragraph, I cannot see that specifying Roman,
Sans-Serif, and Monotype is mandatory. It also says nothing about math.
It may come natural to you, but for me, as someone not familiar with all
the LaTeX machinery, even the difference between Roman and Sans is elusive.
>> >> Where I do have slight problem is "emoji" (or other script
>> >> name). Consider
>> >>
>> >> ("math" :font "Stix Two Math")
>> >> ("main" :font "FreeSerif"
>> >> :fallbacks (("mathematical" "Noto Serif")))
>> >
>> > That has never happened to me. I have seen 'symbol', but never
>> > mathematical.
>> > And maths are quite well covered with \setmathfont and
>> > \usepackage{unicode-math}.
>> > If and when we have to cross that bridge, we will see.
>>
>> Ok. I will agree with your position here for now, but make sure to do
>> RFC to hear from others after we finalize other aspects of the variable
>> value formats.
>
> Reading through your slight objection, I don't think I fully grasp what
> your reservations are. We are mapping a string from a message produced by
> Emacs to a system font when there are indications that this string point to
> a Unicode glyph range not included in the system font we use in the
> document.
My problem is that
("<some name>" ...)
and :fallbacks (("<some name>" ...))
look similar and may be confused.
That's all.
I have no issue with explanation in the manual, I have an issue with
practical implementation - no matter how good the value is documented,
if the structure leaves space for confusion, I will eventually forget,
will have to reach to the manual every time, and get annoyed.
That's why I insist on consistent value formats that are (1) easy to
remember (that is - not changing as much as possible between
fontspec/babel/polyglossia); (2) clear enough to understand the meaning
*without* having to go to the manual/docstring every single time I need
to write the values.
>> (setq-default org-latex-fontspec-config
>> ...
>> #+BEGIN_SRC elisp
>> ("mono" :font "TeX Gyre Cursor"
>> :features ("Color=blue"
>> "Scale=MatchLowercase"))
>> ...
>>
>> As discussed, we should also allow
>> ("mono" :font "TeX Gyre Cursor:Color=blue,Scale=MatchLowercase")
>>
>
> If you continue reading in the manual:
> ...
> :features ("Color=blue"
> "Scale=MatchLowercase"))
> ...
> :features "Color=blue,Scale=MatchLowercase")
> #+END_SRC
I think I was not clear enough. I did read the manual. What I want is 3
ways to specify features:
:font "Name:features"
:font "Name" :features "..."
:font "Name" :features ("..." "...")
There are currently only 2 for fontspec. I want all 3, so that
everything is consistent between fontspec/babel/polyglossia.
>> You can declare the fallback fonts for missing scripts in the
>> ~:fallback~ property based on this list. It consists of an
>> associative list that maps the script names as detected by Emacs with
>> their fallback system font and optional extra configuration.
>>
>> We can probably point to
>> M-: (char-table-extra-slot char-script-table 0) RET
>> as a way to consult what scripts are known by Emacs
>> (I took it from 34.6 Character Properties in Elisp manual)
>
> Isn't it much easier to tell people too look for the script list generated
> by the exporter and starting from there?
> And this is what my Emacs shows both in the minibuffer and in the
> *Messages* window:
> [image: image.png]
> Where are the emojis there? I would be extremely confused. Whereas if I see
> a messages telling me which scripts are detected during the export process,
> I have a (more solid) base to start investigating.
Good point. Then, I would provide some examples of the script names.
>> :fallback (("emoji" . "Noto Color Emoji:mode=harf")
>> ("han" . "Noto Serif CJK JP")
>> ("kana" . "Noto Serif CJK JP")))
>> ...
>> I do not like that fallback is an alist, while the main config is using
>> plists.
>>
>> What about
>>
>> '(("main"
>> :font "TeX Gyre Termes"
>> :fallback (("emoji" :font "Noto Color Emoji:mode=harf")
>> ("han" :font "Noto Serif CJK JP")
>> ("kana" :font "Noto Serif CJK JP")))
>> ...
>>
>
> Would you be more happy if we allowed both?
Yes. But I would still prefer my variant in the manuals.
>> . ((org-latex-polyglossia-font-config
>> . (("en" :font "FreeSerif")
>> ("en" :variant "sf" :font "FreeSans")
>> ("en" :variant "tt" :font "FreeMono")
>> ("he" :font "Hadasim CLM"
>> :props "Script=Hebrew")
>> ...
>> Let's drop ("en" :font "FreeSerif"). It implies :variant "rm", but we
>> should recommend specifying :variant explicitly. Maybe even make
>> :variant mandatory.
>
> Once again, if you read through the manual, you will see:
>
> 2. ~:variant~: a string for the font variant (e.g. ~sf~ for Sans
> Serif, ~tt~ for Mono, ~rm~ for Roman aka. Serif). The variants
> are [[https://en.wikibooks.org/wiki/LaTeX/Fonts][the two-letter
> codes used in LaTeX for the different font families]]. When no
> variant is indicated, it is assumed that the serif font family
> (~:variant "rm"~) is implied. It is recommended that you always add
> variant =rm= *explicitly*.
>
> Isn't that enough?
No, it is not. I am very confused why you need main/sans/mono for
fontspec but rm/sf/tt for babel/polyglossia. I would like to use
consistent names everywhere (be it main/sans/mono or rm/sf/tt)
The reason is the same - if I write a fontspec config and want to
copy/paste it to, say, polyglossia, I am sure I will forget to change
main/sans/mono to rm/sf/tt, will get errors, and get confused.
> Also, what about
>> (("en" "main" :font "FreeSerif")
>> ("en" "sans" :font "FreeSans")
>> ("en" "mono" :font "FreeMono")
>> ("he" "main" :font "Hadasim CLM" :features "Script=Hebrew")
>> ...)
>
> That looks really confusing to me...
I am looking at fontspec vs. polyglossia/babel configs:
("mono" :font "TeX Gyre Cursor")
("en" :font "TeX Gyre Cursor" :variant "mono")
and I feel that I will get confused by where to put "mono" when.
Let's go another way...
What about using full plist?
(:family "mono" :font "TeX Gyre Cursor")
(:lang "en" :family "mono" :font "TeX Gyre Cursor")
This second looks much easier to understand (without having to reach to
the manual every time), IMHO.
>> 2. We replace "sf"/"rm"/"tt" with "main"/"sans"/"mono" - this is to
>> reduce confusion about latex terminology. (We may still allow
>> "sf"/"rm"/"tt" as aliases, for people familiar with LaTeX)
>
> My gut feeling is that this will confuse people who browse through the
> suggested bibliography.
> If we want to be strict, it would be allowing aliases "main","sans" and
> "mono" and not the other way round.
No problem. For me, the most important thing is to be able to copy/paste
and edit between fontspec/babel/polyglossia configs without getting
unexpected surprises.
> 3. :props -> :features. As discussed, I want the same things to be named
>> with the same keywords.
>>
>> Same for babel (:props -> :features, "lang" "main/sans/mono")
>>
> Once again, the fontspec references speak about font features while the
> polyglossia/babel sources mostly use properties.
> Introducing new terminology will confuse people.
>
> With a ton of reservations, but I would introduce :features as an alias to
> :props.
But aren't fontspec's features and polyglossia/babel properties the same thing?
If they are, I am ok with an alias.
--
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
