Thanks for your help so far. I have released the new version. Unfortunately there seems to be another bug (not in my package, but in the Charis SIL font). I spotted it after the release. I have requested the CTAN managers to hold the announcement if possible. All the PDFs are messed up because of wrong rendering of the IPA characters. You can check the latest PDFs from the git repository or from the CTAN page of the package.

Anyways closing this bug report now. Thanks again :)

Sorry for the missing link.

[...] has mentioned here that it might [...]

> Redundancy can also be an objective problem (although it might be subjective what kind of redundancy is too excessive), in my opinion.

Exactly! The feeling of whether something is needed or not is (at least in this case) just personal.

> Ah, I think I've found an inconsistency.

This is an intended inconsistency, because I actually just ignore the empty/noval fontspecoptions and do nothing, but I do not just ignore the empty/noval documentfont option. There is a behavior (selecting the value of a non-empty documentfont if given) which is not the same with fontspecoptions. Also I had specifically said logical inconsistency. e.g. Like spotted in this comment of mine where the same setting is behaving inconsistently. The inconsistency you have mentioned isn't the one which I was talking about. Such inconsistencies are bound to occur with different behaviors of options.

> Completion of the codes for the cases which is not treated yet.

Rather than having code for all of these cases I have added a few lines in the documentation. The value-taking options and non-value-taking-options are now separated in the documentation. Please refer to the latest PDF or the dtx. In my opinion matching each and every option isn't necessary. Also the error message from package expkv is also pretty helpful. With a clear documentation I guess this won't be a problem.

> As the warning message for a `fontspecoptions` with no value.

I have pushed some code now which has the change you have mentioned here. I liked it. Thanks.

Ah, I think I've found an inconsistency.

The case of a `fontspecoptions` with no value is defined as
new noval fontspecoptions = {% \PackageWarningNoLine{tipauni}{% As you haven't given any value to package option\MessageBreak `fontspecoptions'; it will be ignored% }% },%

And its warning message is shorter than that of a `documentfont` with no value.

> Maybe let's agree to disagree here :)

All right. The project is yours.

> The reason I am saying this is I don't have any objective reason for why I think it is necessary and neither do I see any objective problem (like, say, logical inconsistency) in these messages. Two people having two different minds can maybe never agree on subjective points, so in my opinion we shouldn't waste our energy in justifying our (including mine) subjective points.

Redundancy can also be an objective problem (although it might be subjective what kind of redundancy is too excessive), in my opinion.
I think the eventual purpose of my efforts about this is just to make the code and the design more simple. But that has reminded me of the diffenrence between our preferences about coding.
So, I agree to disagree here :).

> Please, provide a valid fontname.

I liked this. I'll make this change. Thanks.

> Now, I think it is unncessary, because it is useless for fixing the wrong usage of documentfont.
> But, I don't think such a care is necessary.

Maybe let's agree to disagree here :)

The reason I am saying this is I don't have any objective reason for why I think it is necessary and neither do I see any objective problem (like, say, logical inconsistency) in these messages. Two people having two different minds can maybe never agree on subjective points, so in my opinion we shouldn't waste our energy in justifying our (including mine) subjective points.

Is there anything left now? If not, I will push the changes with the documentation as it is and use the code with the change mentioned in this message.

Sorry, there were some grammatical errors which are resolved in the following.

The first one:

The second one:

Now, it is an error, not a warning.
So it has come up to mind that a result of an error can be any, or even undefined.

So the messages can be
"The `documentfont' option has no value."
"The `documentfont' option has an empty value."

or,
"The `documentfont' option has no value, and its result is undefined."
"The `documentfont' option has an empty value, and its result is undefined."

or,
"The `documentfont' option has no value, and it is ignored.
"The `documentfont' option has an empty value, and it is ignored."

Although the last candidate requires modification of the design, it will make the codes simpler.

Currently, I prefer the first candidate or the last one.

About the comment #155 of mine.

> > Also the errors are thrown in both the cases.
> I think these behaviors are consistent.

Sorry, this is ambiguous.

I mean it is consistent that errors are thrown in both the cases,
from the viewpoint about which is thrown, an error or a warning.
(I don't mean the error messages are consistent. I don't mean the other behaviors are consistent.)

Sorry.
The message and the results of comment #155 is that of
\usepackage[% documentfont={cmr10}, documentfont=, ]{tipauni}

The second option is `documentfont=`.

In reply to comment #151 and comment #152

> now I have removed the warning messages, but please note that it is still not equivalent to the preservefont. The \tipauni@document@font is still set conditionally.

In this case, the help message and the results conflict.
\usepackage[% documentfont={cmr10},% documentfont,% ]{tipauni}

Help message:
The `documentfont' option has an empty value. Your document will be compiled with the default font-family of (Xe/Lua)LaTeX, i.e., Latin Modern unless another font is set.

Results:
\tipauni@font=cmr10 \iftipauni@document@font true \tipauni@font@options= \f@family=cmr10(0)

> Also the errors are thrown in both the cases.

I think these behaviors are consistent.

I doubt the long warning messages are useful.

When a user see a warning or an error about a wrong usage of documentfont with a reason (no value, or an empty value), it suffices to help fixing.

On the other hand, in the current design, a documentfont option with no value or with an empty value might be used as an option for debug in order to know what font (including a case of no font) is to be loaded at that point (assuming not otherwise specified later). If such a usage is intended, it's better to have some debug option(s)... (in my opinion),

Okay. I would have still kept it, but I spotted another problem, which is in a case like following.

This would lead to inconsistent behavior if the options are flipped. The above example results in errors, but if you reverse their order, no error will be prompted. Hence now I have removed the warning messages, but please note that it is still not equivalent to the preservefont. The \tipauni@document@font is still set conditionally.

Sorry for the wrong wording, I meant the other case is the one when the documentfont option is passed with an empty value or without a value, but some font has been loaded successfully with the `tipauni' package.

> I am not sure if I understand you correctly, what do you think I am assuming?

Assuming there is no font defined before the current option.

In reply to comment #142

>> These codes are for warnings not for errors.

>You are right, but these codes are used only when \tipauni@font is defined before loading the current option.

I know it, and it means they do not always cause errors when documentfont has no value or an empty value.

Implicit assumptions are apt to cause misunderstanding, in my opinion.

In reply to comment #139,

> `documentfont` and `documentfont=` do not behave like `preservefont`.

>They just don't set \let\tipauni@font\tipauni@undefined. I don't see any reason where it would be absolutely necessary. Behaviorally they match exactly as setmainfont isn't executed. Code wise they don't match, I agree, but why would you insist to make \tipauni@font* undefined by \letting it be \tipauni@undefined?

In order to avoid unexpected bugs, the states of the parameters should be controlled exactly, in my opinion.

And, clearly, \tipauni@document@fonttrue does not match.

In reply to comment #138:

> > Another choice (change of the design), is that both of `documentfont` and `documentfont=` should cause errors.

> They do!

These codes are for warnings not for errors.
So they doen't do unless the codes are dead.

> `documentfont` and `documentfont=` do not behave like `preservefont`.

They just don't set *\let\tipauni@font\tipauni@undefined. I don't see any reason where it would be absolutely necessary. Behaviorally they match exactly as setmainfont isn't executed. Code wise they don't match, I agree, but why would you insist to make \tipauni@font* undefined by *\letting it be \tipauni@undefined*?

Another choice (change of the design), is that both of `documentfont` and `documentfont=` should cause errors.
I guess you proposed it formerly at first from the viewpoint of semantics (I'm not sure).

But this time, treat an empty string as a usual fontname, and
it brings an error from \setmainfont. This is same as a case in which a given fontname is wrong.

It will simplify the codes.

This is not modified yet (cf. Comment #127)
`documentfont` and `documentfont=` do not behave like `preservefont`.

Keep the definition of `preservefont` in mind.
noval preservefont = {% \let\tipauni@font\tipauni@undefined \tipauni@document@fontfalse },%

The definition of `documentfont` (with no value) doesn't match that of `preservefont`.
noval documentfont = {% \ifdefined\tipauni@font \PackageWarningNoLine{tipauni}{% A `documentfont' option has no value, but you have\MessageBreak loaded another font with some tipauni-option, so that\MessageBreak font will be used as the main font of this document\MessageBreak unless another font is set. The last active font\MessageBreak being currently loaded is: \tipauni@font }% \tipauni@document@fonttrue \else \PackageError{tipauni}{No value for the `documentfont' option}{% The `documentfont' option has no value. Your document will be compiled\MessageBreak with the default font-family of (Xe/Lua)LaTeX, i.e., Latin Modern unless\MessageBreak another font is set.% }% \tipauni@document@fontfalse \fi },%

The definition of `documentfont=` (with an empty value) doesn't match that of `preservefont`.

> Is there any case in which it does not work?

Expansion is a weird beast in TeX and I am no expert in this area and hence I have transferred your question as it is to Jonathan Spratte here. Let us wait for their response.

> I guess, generally speaking, the more we want to control, the more we'd care to keep consistency and clarity. And the codes will follow.

You are right, but I guess I have reduced the complexity way too much now. All the code can be easily seen and comprehended in one glance. I had made it **so** complex that even I wasn't able to understand it (very sorry for that), but if 1) the current code satisfies the requirements (which both of us believe that it does) and 2) we test it enough (which also I believe with the l3-test-suit I have managed to do. I plan to increase the test-files.) 3) and it is not absolutely incomprehensible; I guess we can give it a try.

For what purpose, is it necessary to do `\let\tipauni@font\tipauni@recommended@font` even when \tipauni@document@fontfalse ?

It is better like this (in my opinion):
\iftipauni@document@font \ifdefined\tipauni@font \else \let\tipauni@font\tipauni@recommended@font \fi \expandafter\setmainfont\expandafter [\expandafter{\tipauni@font@options}]{\tipauni@font} \else ... \fi

> > Do you mean by "not used correctly", a case in which `documentfont` has no value (`documentfont`, withtout `=`), and a case in which documentfont has an empty value (`documentfont=`, with `=` but with an empty value) ?
> > If so, I agree that `documentfont` should behave like `preservefont` in these cases. And, it was the first solution :) (cf. https://puszcza.gnu.org.ua/bugs/?539#comment0).
> > I'll be happy if this is accepted.

> Great! :) I see that it was what you already had proposed. I don't know why I thought loading CharisSIL would be better in such cases, but never mind. I agree with you now. It seems that we agree on most (all?) of the points now.

I agree most, but not all :).

I don't think so, because the situation is as same as

> Seeing multiple font-names while only the last one will have the effect

> Also we can't really specify ALL the names.

...

> This will report two names. 1) cmr10 2) DoulosSIL; while we had loaded three fonts. The lmr10 cannot be reported with the current design and I don't see any obvious way to report it.
> Therefore it feels weird, but it seems reasonable to report the name of the last active font too. It just gives a detailed picture of the used code. Hence I am a bit confused.

What is resolved would you think?

And it could be an extreme choice: leave fontspec matters to the fontspec package, and make these options deprecated...

> I'll be happy if this is accepted.

Great! :) I see that it was what you already had proposed. I don't know why I thought loading CharisSIL would be better in such cases, but never mind. I agree with you now. It seems that we agree on most (all?) of the points now.

> Please, clarify the points of weirdness. They could be clues to a solution.

Seeing multiple font-names while only the last one will have the effect feels weird to me. Also we can't really specify ALL the names. e.g. Try this:

This will report two names. 1) cmr10 2) DoulosSIL; while we had loaded three fonts. The lmr10 cannot be reported with the current design and I don't see any obvious way to report it.

Therefore it feels weird, but it seems reasonable to report the name of the last active font too. It just gives a detailed picture of the used code. Hence I am a bit confused.

Hello Lemures,

After a long code review which happened here; I have changed the design of the package-options. The latest code is pushed to the `exp-warnings' branch. I have removed a lot of unnecessary conditionals. I have used a faster package for options. I have removed the complicated and bug-prone processing of conditional cases. Though your wish was just to `avoid unconditional loading of CharisSIL', I believe it has eventually brought a lot of good things into the package.

# Regarding https://puszcza.gnu.org.ua/bugs/?539#comment116

I thought about this problem. Currently my viewpoint is if a person has used documentfont option, certainly they want to change CharisSIL. They haven't used the option correctly is a problem that we have understood, but still as we are sure that they don't want CharisSIL, we can directly shift to lmr in my opinion. Would like to hear more about this from you.

# Regarding https://puszcza.gnu.org.ua/bugs/?539#comment115

You are correct. I have made this change.

# Something similar to https://puszcza.gnu.org.ua/bugs/?539#comment75

If you now load the package like this:

You will get this in your log:

Do you think this is desirable? Honestly speaking, I am unsure about this. It looks okay, but weird too. Would like to hear your thoughts regarding this.

Apart from this, there were **so** many things discussed on this thread that at a point of time I felt absolutely lost. If I have missed any of your points, 1) Sorry about that, 2) Please bring it to my notice again. Ignoring your point wasn't the intention. It's just that it might have slipped out of my mind unknowingly.

Hello Lemures,

I will need more time to work on all the points that are so far mentioned as well as here. I will come back with something better. Thanks for your patience.

It seems that the name of the file `empty-and-nonempty-documentfont.lvt' <https://git.gnu.org.ua/tipauni.git/tree/tipauni/testfiles/empty-and-nonempty-documentfont.lvt?id=28c7fdc1f3fa2dc13f2bae68002732b45a10a15d> should be renamed to `nonempty-and-empty-documentfont.lvt'.

The order of thw words `nonempty' and `empty' seems to be reversed.

>> 2. The phrase `So if a \verb|documentfont| is added after a \verb|preservefont|, the former will override the later' makes sense.
>> But, the situation is that `the former' one is placed after `the latter' one in a sequence of options, here.
>> This semms like a situation that there are a green-colored word 'red' and a red-colored word `green'.
>> So, it makes me uneasy.
>> And, I guess, this would be an improved phrase
>> ----
>> So if a \verb|documentfont| is followed by a \verb|preservefont|, the former will be overridden by the latter.
>> ----
> Again, the phrase you have suggested isn't wrong, but I think you are missing the fact that the documentfont option can also override the preservefont if it has the highest priority. So there is nothing wrong in my statement too. For the clarity, I have made the statement like following:
> ---
> Please note that every option so far mentioned can potentially override each other. e.g. If a documentfont is added after a preservefont, the former will override the latter (& vice versa). It is true for all these three package options.
> ---

I know the sentence makes sense and nothing wrong.

I guess, using `E.g.,' here, as you write, is very proper. In fact, the phrase after `So' was just a specific example for telling how the rules worked, and so the phrase did not need mentioning about all cases.
So I think `(& vice versa)' is unnecessary as the pharse you write previously.

But my concerning point is somewhat diffrent.
Maybe my explanation was bad.

My concern is that the properties of the contents does not seem to fit what they are called.

I would be perplexed in the situation when I am orally asked to select the former one from a written sequence of the strings `the latter one' and `the former one', because the contents of the strings does not fit what they are called.

Expressions like this would need careful reading, and might exhaust readers, just in my opinion (not necessary to mind it).

Thank you for your patience.

> It refers neither a case in which recommendedfont is used, nor a case in which none of recommendedfont and documentfont is used.

The description is now:

---
This option can be used to set options to the font set with documentfont package option. If the recommendedfont option is used & has the highest priority; the options set with fontspecoptions will be used with the Charis SIL font. If the preservefont option has the highest priority, this parameter will be ineffective & throw a warning. In the argument of this option write as if you are writing in the optional parameter of the \setmainfont command.
---

I am adding a general note after resetfontspecoptions which is like following:

---
As noted for the font-options, these parameters which deal with the options of the loaded fonts also can override each other. The last one loaded will be considered of the highest priority.
---

In the commit https://git.gnu.org.ua/tipauni.git/commit/?id=d9097a0970f3f2b5221c68f5046883b7284d57d0

It refers neither a case in which recommendedfont is used, nor a case in which none of recommendedfont and documentfont is used.
If it is intended, an explanation for those cases is also required.

And, if it is intended, it should be explained that every fontspecoptions or resetfontspecoptions overrides each other, i.e., the last specified one of fontspecoptions or resetfontspecoptions is effective (overrides the other(s), if any).

Apologies for the mistakes. All of them are corrected now.

I'll start a code review now.

In the commit https://git.gnu.org.ua/tipauni.git/commit/?id=d9097a0970f3f2b5221c68f5046883b7284d57d0

A documentation of resetfontspecoptions is identical to that of recommendedfont.
+% \begin{function}{resetfontspecoptions} +% This option is used to override other font definitions made with option +% \verb|documentfont|. Charis SIL will be used as the main font of the +% document when this option is used. % \end{function}

If this is intended, resetfontspecoptions would be unnecessary.

In the commit https://git.gnu.org.ua/tipauni.git/commit/?h=exp-warnings&id=0c4a7bb4260ad0503e6cdc308099006a25fc34d4

But these two are not bugs in the documentation.

> Note that it has a few extra changes which are not present in the patches I have so far sent here.

In the commit https://git.gnu.org.ua/tipauni.git/commit/?h=exp-warnings&id=d9097a0970f3f2b5221c68f5046883b7284d57d0, an documentation about the `incompatible' option is silently removed.

But I don't know whether it is intended or not.

After the file #471, the code in comment #96 made an unexpected result, until the file #488.

> I believe that I have developed all the features you requested for.

Yes.
They are more than what I requested, since all I need is the option preservefont.

> So can we postpone the decision regarding the warning messages for the time being?

I agree.

Thank you for developing the package!

> I posted it as a reformatted memo of comment #77, which I thought being discarded.

Yes I missed it.

> It is newly suggested under the assumption you might want it. I don't know whether you want it or not.

Initially I wasn't much convinced, but then I thought it is a feature worth developing by the same logic that I applied to others. One might want to just forget everything and load Charis SIL by a simple \PassOptionsToPackage command and for which two three lines of code won't hurt. So I developed it.

> Now, both of us have agreed, don't we? :).

Yes! I am glad :)

> Except about the warning message, I guess, both of us have agreed. Do you?

Yes, fully!

I think the only point where we are disagreeing is whether having three cases of ignoring the empty documentfont is necessary or not. In my opinion as far as we can help the user with knowing what is most possibly going to happen with the code they have used is a good thing. So even after ignoring the empty documentfont, we are implementing 3 different behaviors based on other options they have/have not used. Giving information about it is not a very bad idea in my opinion. There is only one case where my warnings can contradict. It is when users use fontspec commands or default font-changing commands outside of package tipauni. I think my warning message covers that case too as I have mentioned tipauni-external methods.

So I have the following proposal. I will first document the code so far we have consolidated. Create a git branch for that. Let's hear from the experts. I am not discarding the idea of a simple warning message, but currently I am willing to settle down with the "feature-requirements". I believe that I have developed all the features you requested for. So can we postpone the decision regarding the warning messages for the time being? Please note that I am not discarding your opinion, I just want to hear more voices. I hope that's fine.

Thanks for your help so far :)

One of the candidate definitions of the behavior of the options documentfont, preservefont, and recommendedfont (cf. comment #92).

1. A recommendedfont option (default): do `\setmainfont{CharisSIL}' unless otherwise specified later.
2. A preservefont option: skip doing `\setmainfont' unless otherwise specified later.
3. A documentfont option with a nonempty value: do `\setmainfont' with its value unless otherwise specified later.
4. A documentfont option with an empty value: be just ignored and regarded as not specifying anything, and output an descriptive warning like this:

The `documentfont' option has no value, and it is just ignored.

1. Done now. Please see the patch.

2. Already there and working.

3. Working.

4. I think the initial part is already working as an empty documentfont does nothing in our code. About the warning message, it seems to be a lot manual-like to me. The current code for an empty documentfont has two cases based on whether the preservefont is active or not and both the messages are very explanatory IMO. So I would like to know the reason why you are insisting for a manual-like warning instead of warnings which examine the code and informs the user about their mistakes.

I found a bug in the code which I corrected in the first patch and the warning message was weird which got corrected in the second patch. I am attaching the sty also for the convenience.

Let me know what you think.

(file #485, file #486, file #487)

> I will put this up to review on various sites as well as I'll take help from Jonathan Spratte.

I agree.

> After all nothing is bug-free and easy to maintain. One has to accept this fact and still proceed with the limited resources they have. This is how free software grow IMO.

I agree. And it is valuable not only accepting the fact, but also any efforts to find easier and safer ways to maintain and to fix bugs :).

Thanks for the patch file #479.

For my convenience, I'll post a reformatted suggestion of comment #77.

Now, it seems to be the time to go to a new step.
I'm waiting for an option like preservefont to be implemented.

Thank you for your patience.

> The codes are all of yours.

Sorry, I was so upset.
I mean that all the codes are yours.

> Thanks for pointing the problem case (again). Actually I had developed everything to fix that problem case, but I added a wrong counter number because of which the behavior didn't change. Sorry for that. On line number 556 it should have been counter number 2 and I mistakenly kept it 3.

Oh, it sounds that the codes are difficult for maintenance and are apt to bring bugs...

> Now it is fixed and you will be prompted with the following warning.

Confirmed with file #477 for the case of comment #74.

For which version does the patch file #478 apply?
I tried it after the patch file #476, but it failed.

Thanks for pointing the problem case (again). Actually I had developed everything to fix that problem case, but I added a wrong counter number because of which the behavior didn't change. Sorry for that. On line number 556 it should have been counter number 2 and I mistakenly kept it 3. Now it is fixed and you will be prompted with the following warning.

The correct(ed) sty is attached with the patch.

I have changed the name of the counter too. It is now tipauni@settings. I hope it's safe.

> Honestly speaking, I'm getting tired of checking compiicated codes.

I am so sorry to hear that. I apologize if I have bored you in any manner.

> But practically, I doubt the necessity of taking care of them too much at the expense of too much simplicity of the codes, because absurd cases are just absurd. (Just in my opinion)

It's not just the fun or the pleasure for which I developed these features. I strongly believe that there can be situations where this would indeed be needed. e.g.

Users might just have one main document file with several tex files as \input. They might use commands like \PassOptionsToPackage{foo}{tipauni} in each of the files. If these \input files are shared with someone else and they used them in their main document without thinking of the implications (and trust me; humans do these things :P) our so called absurd situations might turn into real cases!! So please don't be pessimistic about your contributions. As I said they are really valuable.

Apart from this, if you are really bored of all of this, you are free to stop this discussion :)

(file #477, file #478)

It looks okay, but not confirmed that there is no more contradiction.

The name `specialsettings' of the counter could conflict easily.
It looks a rather general word.
It can be used without \makeatletter.
It might be used another package of yours, if any.

The codes seem to become more complicated, since five internal parameters are used just for two options.

Now, the less the messages are, the less the possibily of contradictions. So the changes must be good from this point of view.

Honestly speaking, I'm getting tired of checking compiicated codes.

All I have done is just to pick some contradictions, not to prove the correctness of the codes.

I'm happy to hear that my comments have contributed to your fun.

But practically, I doubt the necessity of taking care of them too much at the expense of too much simplicity of the codes, because absurd cases are just absurd. (Just in my opinion)

Sorry for a delayed response, but these situations were really tricky. I had to change my approach a bit to form the current version of the package. I hope that it takes care of all the points you have so far mentioned. Even the readable version is too long to be posted now XD

I have attached the patch and a derived .sty directly in this mail. Kindly test and let me know.

PS: I loved coding this part. Thanks a ton for providing me with such a variety of absurdity. I am eager to document all of this, I am sure it would be a lot of fun :)

(file #475, file #476)

To be more precise, `unless otherwise specified later' is added to the first three cases, and `regarded as not specifying anything' is added to the other case. `

1. A recommendedfont option: do `\setmainfont{CharisSIL}' unless otherwise specified later.
2. A preservefont option: skip doing `\setmainfont' unless otherwise specified later.
3. A documentfont option with a nonempty value: do `\setmainfont' with its

value unless otherwise specified later.

1. A documentfont option with an empty value: be just ignored and regarded as not specifying anything, and output an descriptive warning like this (but too long):

The `documentfont' option has no value, and it is just ignored.
1. Use `preservefont', when you want the mainfont kept untouched.
2. Use `recommendedfont', when you want the mainfont set to the font
recommended by the package (i.e. CharisSIL).
3. Use `documentfont' with a font-name, when you want the mainfont set to
the font. E.g., `documentfont=CharisSIL', `documentfont=DoulosSIL',
`documentfont=DejaVuSans', etc.

One more example :),

A sample code to be processed with file #474:
\documentclass{article} \usepackage[% documentfont, preservefont, documentfont, documentfont=DoulosSIL, ]{tipauni} \begin{document} Hello world \makeatletter\f@family\typeout\f@family\makeatother \end{document}

A log contains:
Package tipauni Warning: The `documentfont' option has no value. Your (tipauni) document will be compiled with the default (tipauni) font-family of package tipauni, i.e., Charis SIL (tipauni) unless another font is set with tipauni-external (tipauni) methods. Package tipauni Warning: 1. The `preservefont' option is active. (tipauni) 2. The `documentfont' option has no value. (tipauni) Your document will be compiled with the default (tipauni) font-family of (Xe/Lua)LaTeX, i.e., Latin Modern (tipauni) unless another font is set with tipauni-external (tipauni) methods. ) (./c75.aux) (/usr/share/texmf-dist/tex/latex/base/ts1cmr.fd) DoulosSIL(0)

All right.
Then, another case...
A sample code to be processed with file #474:
\documentclass{article} \usepackage[% documentfont,% preservefont,% ]{tipauni} \begin{document} Hello world \makeatletter\f@family\typeout\f@family\makeatother \end{document}

A log contains:
Package tipauni Warning: The `documentfont' option has no value. Your (tipauni) document will be compiled with the default (tipauni) font-family of package tipauni, i.e., Charis SIL (tipauni) unless another font is set with tipauni-external (tipauni) methods. ) (./c70p.aux) (/usr/share/texmf-dist/tex/latex/base/ts1cmr.fd) lmr

But I doubt the necessity to take care of an empty `documentfont` so subltely, since it is absurd by itself.

The definition of an emtpy `documentfont' will be more simple,
if it is independent of \preservefonttrue and \preservefontfalse.

Just in my lazy opinion
(although I know this is a modification of the design).

Thanks for the correction. I forgot to add \charissil true in one of the if conditionals. Corrected now. Also I have edited the warning message and written (Xe/Lua)LaTeX instead of just LaTeX. Commas are added now.

Thank you. The readable format is helpful.

I doubt this part of the message:

the default font-family of LaTeX i.e. Latin Modern

It seems true for LuaLaTeX and XeLaTeX.
But, it's not true for LaTeX, obviously.
So, I feel very uneasy...

`i.e.' in this case might need commas before and after it.

`tipauni-external' seems a newly coined word, although it is understandable.

Another example would be better "Keeping the current setting for font (and font features)".

I must admire your skills at creating such tricky situations! I am stuck here. I understand the problem, but I am not sure how to tackle it. Because, if we test \ifx\f@family\@empty, it also involves cases of earlier successful loading of documentfont. e.g.

Or even preservefont which defaults to LMR.

So I don't know how to proceed further.

(file #472)

Cool!

So are we good to go with the current design?

> I guess what I expect from preservefont might be called preservefontandfontspecoptions or preservefontandfontfeatures from your viewpoint.

Correct!

> Although the name of the command `\setmainfont' contains neither `options' nor `features', the command treats font features as a option (treating font features as empty even if not specified).

Yes, I agree with this, but it is a command from package fontspec. The distinction I am trying to draw here between preservefont and fontspecoptions is of that package only. preservefont doesn't use package fontspec at all as it doesn't load any font. If that is the case, my names are already very intuitive. If you want I can make it something like preserveltxfont or nofontspec for example.

In this case also I feel the names themselves shall trigger the warning. I could have said 'fontoptions', but I deliberately said `fontspecoptions'. The reason why your case won't produce what you are expecting is you are simply not using anything given by fontspec.

I feel adding a warning in this case is unnecessary. With so specific names for the options such as preservefont and fontspec*options, I believe it is fundamentally wrong to even think that preservefont might cancel the fontspecoptions. I feel looking at the results even the names themselves shall trigger a warning to the user. Adding an actual warning would be to noisy in my opinion.

I assure you that I will describe these options well in the documentation.

Kindly ignore file 470 and use the following patch.

(file #471)

A similar case in the comment #48:
\documentclass{article} \usepackage[% documentfont=DoulosSIL, documentfont, %% Expected %% The behavior and the warning should be consistent. %% Results %% \setmainfont{DoulosSIL} %% warning about documentfont, which says loading Charis SIL %% i.e. the results and the warning are contradictory. ]{tipauni} \begin{document} Hello world \makeatletter\f@family\makeatother \end{document}

Thanks for pointing this case! Fixed.

(file #467)

Fixed!

Anything else?

(file #466)

But in this case, I think the warning about `fontspecoptions' can be omitted to avoid bothering.

If I understand you correctly,

This is the case you are talking about, but with the latest code, this indeed throws a warning. The warning message is as follows:

Can you demonstrate with code the situations in your mind and tell me which warning messages you expect there?

Oh sorry I meant "[...] a simple warning message along with loading Charis SIL [..]".

All right. I see.

By the way, what about the second type of warning which I suggest in the comment #31.
Do you mind adopting it?

This will bring a warning in cases like the one in comment #26.
But the case in comment #26 is rather absurd (containing unnecessary `preservefont'), so ordinary users will not be bothered by this warning.

From a viewpoint of me as a user, the warning message is rather long to get the point. It looks like a detailed explanation in a manual.

I guess, it would be helpful for users that warning messages are concise and explicit about the cause of warning.
And a phrase like `See the manual for details.' might be useful in a warning message in order to make the user read the manual :).

And, I admit my first warning message is also too long, from this point of view.

Thank you for checking my patch.

> Control sequences in your patch had rather complicated names, which I changed for the maintenance's convenience.

I agree, Thank you.

> Your patch issued warnings with simple usages of `documentfont' too, which might be a bit too noisy for some users

Please tell me a particular case.

With the patch file #463, no warning is issued in this case:
\documentclass{article} \usepackage[% documentfont=CMU-Serif,% ]{tipauni} \begin{document} Hello world \end{document}

The first sentence of the new warning message in file #464
looks too complicated for me.

And preservefont makes documentfont ineffective and keep its fontname, i.e. preservefont does not totally clear documentfont.

I think the reason why I want warnings, again.

Warnings will be useful for such people like me who might think that preservefont would override both of documentfont and fontspecoptions although it overrides documentfont only.

From this point of view, I guess the case of Comment #26 needs a warning.

So, I add another warning for cases like this.

(file #463)

Please try the patch file #462, which is to be applied after the patch file #461.

A warning might be helpful when the following \if is true at the end of options.

Sorry for too long name. It can be another appropriate name.

Assume this \if is named as \if@tipauni@warning@ (just for short), for the time being.

The following algorithm is a suggestion.

How to set this \if@tipauni@warning@:

1. At the beginning, set \@tipauni@warning@false.
2. preservefont and documentfont set \@tipauni@warning@false.
3. fontspecoptions with an empty value sets. \@tipauni@warning@false.
4. fontspecoptions with a nonempty value while \iffontpreservation is false, then set \@tipauni@warning@false.
5. fontspecoptions with a nonempty value while \iffontpreservation is true, then set \@tipauni@warning@true.

And output a warning \if@tipauni@warning@:
\if@tipauni@warning@ \PackageWarning{tipauni}{`fontspecoptions' is ignored when `preservefont' is effective at the end} \fi

I feel it is better. Thank you.

Other points:

1. People like me might be puzzled when preservefont is effective and fontspecoptions is not empty since fontspections is silently ignored. So, I think it is helpful to output a warning through \PackageWarning in such cases.
2. resetfontspecoptions might be unnecessary because it is just an alias of 'fontspecoptions' (without a value) or 'fontspecoptions=' (with an empty value).
3. Since \ifnocharis is false if and only if \tipauni@font is empty, \ifnocharisfalse (and \newif\ifnocharis, which sets \ifnocharisfalse) can be replaced by \let\tipauni@font\tipauni@font@default while \tipauni@font@default is defined as \def\tipauni@font@default{CharisSIL} earlier. (Just in my opinion. I know it depends on preference about coding.)

Thank you, निरंजन!

It looks good to me about documentfont and preservefont options. Thank you again for accepting my wish.

However, when it comes to adding fontoptions, it seems complicated.

I know I'm too obsessive about absurd situations, but human beings can do absurd things. So, I add a few cases to be considered.

Among them, two cases (marked with `!!!' below) bring different results from my expectations.

Thank you for struggling with my wish.

But, I'm afraid that a mixture of documentfont and fontoptions options would be too complicated...

I think that DoulosSIL or DejaVu Sans could be other candidates besides CharisSIL.

By the way, ...

What if there is a macro which checks whether a font contains all the IPA characters?

What if tipauni package outputs a warning if the macro fails, so that authors can know the failure through logs (as a default, this check would be done in \AtEndOfPreamble or \AtBeginDocument, or at the time of loading tipauni package)?

I think the following code should solve most of your complaints plus add another functionality to add options to the font being selected:

Loading Charis SIL is a very necessary step. Merely rendering IPA in Unicode doesn't mean anything to a common user. If they can't see the output, it's almost useless for them. The Latin Modern font doesn't have a lot of IPA characters. The Computer Modern Unicode has most of them, but still there are some characters missing and some characters have weird shapes. Hence loading a perfect Unicode font was necessary and therefore I selected CharisSIL.

Please don't feel sorry for reporting your opinions and suggestions. They are much valued! :-)

Anothoer choice might be removal of \setmainfont{CharisSIL},
because there is no meaning about changing fonts in the text \usepackage{tipauni}.

This is a very simple change.
And each documentfont option executes \setmainfont immediately.
Although it causes a backward compatibiliy issue, it seems semantically correct.

Does this make sense?

I apologize for posting many times.

Thank you for developing the package!

A patch for fix (comment #14) is uploaded as file #457.
It can be applied to the commit aadf596abb3f0a0a3203de51a94cbce765cd151e.

Regards,

I think I've understand it.

My wishes are:

1. documentfont and preservefont have same priority.

and

1. When a documentfont has the highest priority, do \setmainfont with its value, and ignore all the other documentfont and preservefont.
2. When a preservefont has the highest priority, skip doing \setmainfont, and ignore all the other documentfont and preservefont.
3. Neither documentfont nor preservefont has specified, do as if documentfont=CharisSIL is specified.

Pardon the weird formatting.

I am also learning this new markdown syntax.

By the way, what is the problem about the solution by the file #450.

In this solution, it uses only one concept documentfont. And it is very simple:

1. As a default, \tipauni@font is CharisSIL.
2. A documentfont option sets its value to \tipauni@font.
3. If \tipauni@font is non-empty, do \setmainfont with it.
4. Otherwise, skip doing \setmainfont.

So, I guess, it is unnecessary to create a new option preservefont, in fact, when patched by the file #450.

But, I don't hate defining an alias of documentfont= (documentfont option with an empty value).

Regards,

In short, although `documentfont` can be overridden by another `documentfont`, `documentfont` cannot be overriden by `preservefont`.

I feel these situations are confusing (I know the absurdity):

(1) `\usepackage{documentfont=foo,documentfont=bar}{tipauni}`

`documentfont=bar` is effective.

(2) `\usepackage{documentfont=foo,preservefont}{tipauni}`

`documentfont=foo` is effective.

(3) `\usepackage{preservefont,documentfont=foo}{tipauni}`

`documentfont=foo` is effective.

If I am not mistaken,

is equivalent to

So by this logic, why would someone ever want to use something like this?

The purpose of these two options is completely contradictory, isn't it?

Correct, so what about this?

(file #456)

Won't this be better?

(file #455)