@marmot Of course, and in fact that's one of the particular properties of belief contexts generally. But what I'm saying is that as scientists we don't go about our work thinking everything we do is false, but instead we assume it's true and then work to both support and disconfirm it. And in this respect the formal notion of truth isn't particularly helpful.
@JosephWright It was the graphic (which explains why it said texlive 2017 ;-)). One can suppress it with bit 8, but it is probably not needed -- the graphic should be the same on both systems.
@JosephWright I found a problem with the new -H behaviour: I did run the check, this involved three configs, in the first there was a failure but the fc-file wasn't in the test folder as l3build seemed to have cleaned up when doing the other config.
@JosephWright the pdftex passed with suppressinfo = 3. luatex failed: The format of creation date is different on my system from the one generated by travis. (D:20160520110000+02'00') <-> (D:20160520110000Z). And I had to set the trailerid. - and now it still fails due to a difference in the font count ;-(.
@JosephWright I now removed the graphic (and graphicx) which seems to introduce a line about color and a font from the test and now the build passed. And I'm considering a new repository called "travis-torture-tests" ;-).
@UlrikeFischer Hmm, should I suppress the dates and ID entirely? That might make sense, given what you say, at least for the LuaTeX case (which can be picked out as it needs \pdfvariable)
@UlrikeFischer Are you happy with that? I can change the behaviour but it will be non-trivial
@UlrikeFischer We'll likely be working quite a bit on normalisation: once I know what I need to zap, I can sort it from the post-processing
@WillRobertson asked me a really good question in a comment, and I think this might be a better place to discuss it. But I'll make a new room if people here prefer.
@JosephWright Yes, it is ok. But what I would really like is a file with the sum up of the check which doesn't disappear between tests. New results could be prepended.
I think people here are able to handle multiple conversations at a time. (By the way, as a native speaker of English, I'd interpret "Could experts be lenient about the existence of MWEs?" to be either a polite request, a sarcastic complaint, or a neutral question depending on context.)
@UlrikeFischer @JosephWright @PauloCereda btw, I'm back in Europe, I visited Amsterdam and now I'm in a train to catch my last flight of this whole journey.
@JosephWright well I did reset the variable to 3 so both settings were overwriten. More interesting is why I got a FileName if you already had 2 in it.
@Davislor and @WillRobertson Just from a non-TeXnical viewpoint I would state that \textbolder and \textlighter are semantically easy to understand and much easier to remember than the whole NFSS. Maybe even better semantic markup would be \textstronger and \textweaker (although it sounds horrible). I would not disagree with the other commands for formatting rather than markup though (\textsb etc).
@WillRobertson Most of what I've written in LaTeX is math or CS papers. Like (I suspect) most people here, I have a personal stylesheet I've refined over the years, and when I use something else, it's because that's a requirement.
@WillRobertson For those, I've never needed to use more than two font weights in the text. My use case for something like Semibold or Extrabold in a math paper would be that Bold wasn't the right weight. In that case, I would probably want to set the bold math alphabets to match the bold text font, or otherwise, use arrows over my vectors instead of ISO style.
@Davislor and @WillRobertson I do not use such a personal stylesheet, because I use LaTeX (including different fonts using fontspec) for anything ranging from letters to technical papers which is for me a very good reason to use semantic markup instead of specific formatting, because I do not want to remember "I use light font in my letters, hence I have to 'shift' from there" or "I use regular font in the manual I am writing and have to know the font weights from there".
And believe me you will need more weights (light and bold) in a long manual than in a CS or math paper if you want to stay in the same font family.
@TeXnician I think we agree? All the specific font loading goes into the stylesheet, including setting \textbf to Semibold, and that allows me to use semantinc markup exclusively in the document.
So, for example, when I need to compile with PDFLaTeX, I can just change the stylesheet.
@TeXnician @WillRobertson And yes, I was getting to the more complex cases.
@Davislor Yes, in this respect we agree, but I understood your first comment as "Don't introduce something like \textbolder or \textlighter". And I think these commands would be handy – at least sometimes.
@WillRobertson I could see myself using a different font weight in, for example, titles and headers. In that case, I probably define a new font family or face, but I also might specifically find it useful to add \ebseries (or something like \ebweight from nfssext-cfr) to the fancyhdr/titlesec/memoir/scrbook command defining my headers.
@WillRobertson That’s not a situation where I’d write \bfseries\bolderseries\selectfont.
@Davislor and @WillRobertson I would still favor a context-aware command like \textbolder or something along these lines, because it is much better for the document. Sometimes I only want to write a document and not a whole stylesheet and even then I do not want to remember which font weight I initially chose, but make LaTeX choose it from the context and my semantic markup.
@WillRobertson I’d be more likely to want to use \emph{} within a title than \strong{} when it’s already bold. One case I could imagine where I might want to is if a title wants to both emphasize something and use italics for a different purpose, such as the title of another work or a foreign phrase.
@WillRobertson But to come back to your proposal, I do not think that the specification BoldFont=x, BoldFont=y, BoldFont=z is a good way for the user to input the bold fonts. Maybe you should make a simple map for the user like weightorder={light, regular, extrabold} and have a key for every weight available.
@WillRobertson In that use case, I would want to write it as \strong{} and \emph{} within a title that’s already bold, and I think the package supports redefining nested emphasis.
@WillRobertson I could see authors wanting to specify, “The title should be the same font family as the body text, but ExtraBold.”
@WillRobertson I confess, I've also attempted to start a novel in LaTeX.
@TeXnician — the problem there is that I need to allow the user to set font features for specific font faces. (Well, for varying bold shapes it's unlikely but I don't want to design myself into a corner.) I was thinking something like
@WillRobertson It would honestly surprise me to see "They are coming. They are coming," in darker and darker font weights, outside of a children's book. But I could imagine someone like H.P. Lovecraft doing it.
@WillRobertson If I want something like that, I probably want "Four roughly-equal increases in font weight between normal and ExtraBold," rather than, "Whatever the next-bolder weight is."
@WillRobertson So: \textmd{They are coming.} \textsb{They are coming.} \textbf{They are coming.} \texteb{They are coming.} rather than They are coming. \textbolder{They are coming. \textbolder{They are coming. \textbolder{They are coming.}}} Which might end up as ExtraBold, UltraBold, or Demibold.
Also, if you add a Medium between Regular and Semibold and a Demibold between Bold and Black, that doesn't mess up the "semantic" markup to mean something different.
@Davislor — while I want to allow that usage, it's not really the goal. More that I think there is a definite need to specify more than one weight in a style file and then decide later which should be the default and which should be the "bold" one.
@TeXnician Possibly :) I'm not convinced that all the semi-standard NFSS designations are used enough in practice. But if the old interfaces can be supported, so much the better.
@Davislor But the whole point of semantic markup is to adjust to what you have, so inserting another weight should affect the document. The other way, the formatting markup should of course stay the same.
@WillRobertson I guess that using the "semi-standard" specifications may be the exception, but it's really handy once you need them. And with modern fonts its even more important to make detailed gradations.
@Davislor While this sounds good, I personally would miss the option to mess up control the order of fonts used. With your version I would get the reversed order by specifying a light font as BoldFont which satisfies semantic markup, but then the mapping to NFSS would be gone and therefore formatting markup would be destroyed.
@Davislor So have a whole bunch of weights pre-defined, and allow the user to define more? I think this is quite a user-friendly solution, and I hadn't thought about having an extensible set of weights for the keyval keys themselves.
@TeXnician When you say "control the order", we could also have some macros for indicating how progression along a series would work.
@TeXnician In this case, though, I think I either want to specify the exact typeface of my title or graphic, or I want to specify four gradations between Regular and Black, or I want to specify "Something stronger than this text that’s already bold, but distinct from italic."
@WillRobertson the names don't matter much. Nobody prevents you to define a series with name "blackbear" and map it to a heavy font. So a simple alias system should be able to handle semibold versus sb. The main point imho is that you need an order if you want to define bolder and lighter commands.
@WillRobertson That was my point with the weightorder key I mentioned above or what I would have taken your \NewFontspecSeries for. So basically I would suggest using something like @Davislor's key system which maps to NFSS and simply having a command or key for the order which could be used by semantic markup.
@Davislor But maybe some class I can't control (which are more than I could think of) uses a specific NFSS mapping, so I would use the DemiBold key, but usually this font is meant to be a light font, because I write with heavier weight…
@TeXnician @Davislor @UlrikeFischer — thanks all for comments, I think I'm getting a decent idea about how some of the interfaces here could work. Have to run now — good night!
@Davislor Well no, the other class uses formatting markup, because it uses NFSS mappings, and I want to use semantic markup. But basically your idea should work. Probably I simply would have been too lazy for looking up these commands ;)
@PauloCereda passed the security ... well, with a twist, but passed. On the way from Bocaina, I found a wrench on the road, I picked it up and put in my backpack thinking I'll leave it to you or your dad. However, this never happened, the security at GRU didn't care and now they found it in AMS. However, they even let it through and didn't throw it away.
@Davislor Basically my point is that I simply want to have that option independent of knowing the weight, so \textsb would be formatting markup and not my style for the document. Concerning the nested \strong's this would be an option. But I would miss the opportunity to switch back, e.g. I have a bold heading and want something one level less bold which could be a good use-case for \textlighter.
As example: I want names to be typeset a weight lighter than the "normal" text, so I would define a command \def\myname#1{\textlighter{#1}} which would work in headings and normal text (while this is a definition I do not want to do context-sensitive definitions relying on NFSS on my own).
@TeXnician Right; in standard LaTeX, that's \fontseries{l}\selectfont. You can define a different font family for your headers so that FontFace = {l}{n}{*-Semibold}, but there isn't presently a way to write \strong{My name is \name{Jan Jansen.} I come from Wisconsin,}
@Davislor Well, it's not \fontseries{l}, because maybe I use b for the text and want it one weight less, maybe m for quotes and want it one weight less and ub for headings and want it one weight less. And I certainly do not want to change my headings only because one may contain a special command like this name (like \section{My friend \name{The Duck}}, defining a \sectionWithName wouldn't make sense).
@Davislor Yes, but we are talking about the future, aren't we? And personally I would love if a package like fontspec would ease this kind of definitions. But in this case I'm just a user, so I only try to get my needs across.
@Davislor I don't want to use a specific command from a package I do not even want to include, but I hope to have an option in fontspec in the future which allows me to do this easily. If I wanted I could have the effect today, but sometimes I do not want to write LaTeX code, but simply use LaTeX the way others have designed it (e.g. package authors).
@WillRobertson Also, \lighter and \heavier could coexist pretty well with built-in support for sb, eb, l and so on: when you set the font, the package knows what weights you just defined.
@UlrikeFischer Yes, it is. And basically that's what \strong does at the moment if I'm not mistaking (just using a sequence), but I just had the hope that the user would not have to define it in the future (and the whole discussion started talking about a possible fontspec enhancement).
@PauloCereda I'll manage I think, I'll just look pretty funny you know, a sporty guy with a sporty backpack not being able to go one floor down and up :D
Also, are there a lot of fonts that don't fit well into the Regular/Medium/Semibold/Bold/Demibold/Extra Bold/Ultra Bold schema? With perhaps some name changes such as Book for Regular, Black for Extra Bold?
More than two weights in between Regular and Bold, more than three heavier than Bold?
@Davislor Aliasing sounds more reasonable as most fonts I use do have a Regular weight and only some a Book weight. But the extensible approach which was mentioned previously might be preferable for edge cases.
@WillRobertson Anyway, the first issue I ran into was when I was trying to use the ebgaramond package. The version of EB Garamond 12 that ships with TeX Live 2018 comes only in normal weight, but there's a more complete set of weights on the repo I wanted to use.
@WillRobertson I was thinking at first I could patch it with \defaultfontfeatures[EBGaramond12]{ BoldFont = ... }, but unfortunately, it already defines BoldFont = *-Regular.
@WillRobertson And there doesn't seem to be a way to partially redefine a font that's already loaded. So, I have to rewrite essentially the entire package. Granted, maybe that's something the package should fix.
@PauloCereda Well, you are most likely right. Even if it is not now, given the speed with which the exoplanet guys discover new planets, it certainly will be very soon.
@TeXnician That one has at least two deficiencies. One, ironically, is exactly the same one you were talking about with regard to font weights: it doesn't scale the relative sizes, so it breaks if you use it at any but the default size.
@TeXnician Also, mine does one or two useful tricks like detecting if the font supports real small caps and falling back on fake only when necessary, and autodetecting the language being used and applying its special rules for capitalization.
@Davislor Well I dislike most of the fakes since they do not work with LuaLaTeX (as far as I remember), so I have only used the non-package fake small caps…
@TeXnician I've learned a lot from his answers! But, once or twice, I've been able to improve on one. :)
@TeXnician And mine certainly could be improved; one major flaw is that formatting commands inside my \ersatzsc don't work, so you can only write \emph{\ersatzsc{foo}}, not \ersatzsc{\emph{foo}}. I'm not exactly sure the best way to fix that, but probably parsing the input and recursion?
@TeXnician I ended up not using boxes in the second version; it just calculates a Scale and a Stretch.
@WillRobertson Anyway, the second thing I was thinking about was the part in your talk where you spoke about deprecating the display names and switching to specifying the exact filenames.
@WillRobertson That seems like a step backwards; I'd much rather be able to write \setmainfont{Palatino Nova} and have things Just Work.
@WillRobertson So maybe we should consider shipping a bunch of different .fontspec files that allow the font families in the distro to Just Work, and also turn on the font features they support, such as Common/Rare ligatures?
@WillRobertson I’m particularly concerned that a lot of the filenames could change. It seems pretty likely to me that there could someday be an OTF version of DejaVu replacing the TTF one we have now, for instance.
@WillRobertson And that'd break any document that included Extension = .ttf.
@WillRobertson But, if there's a DejaVu Serif.fontspecon CTAN, just update that and everything that had \setmainfont{DejaVu Serif} will keep Just Working.
@HenriMenke Processing all posts in the postgres database to re-generate the HTML? Note, TeXwelt is django-templatish with Python below and postgres behind. Do you have experience with it?
I am using \rotatebox{60}{\textcolor[rgb]{0.45, 0.98, 0.53}{$\vrectangleblack$}} which provides me with the following symbol:
https://pasteboard.co/Hy5yYf9.png
Although it works for generating the correct symbol on pdf - it gives me the following errors in compiler:
Argument of \Hy@tempa has...
@marmot In trying to push me for the limits of my "just do it for me" definition, you're conflating the question of what the definition is with the (implicit) question of whether such a question should be answered or not. I'm sure we can find some questions which are definitionally JDIFM but are in fact reasonable questions, and conversely, questions with unrelated code that don't meet the definition but are clearly JDIFM.
@marmot But code posted in good faith, even if somewhat far removed from the requested image is still better, IMO than no code at all, and therefore not really JDIFM. (And yes, "in good faith" is purely subjective...)
@marmot Well given that they're both Germanic languages I'd hope they have the same origin. But I had no idea that 'Gift' meant 'poison' in German. The meaning in Old English was 'dowry' or payment for a wife or also 'wedding'. This meaning was around in Old Norse. But Old High German has the poison meaning too. So the split is very old.
@AlanMunn No, it is more that Germans used presents to end discussions, I think. ;-) (BTW, the word retained its meaning in the German word "Mitgift", which is the presents that the parents need to give the new husbands family when they get their daughter married. "Mitgift" is usually not poisoned although its literal translation means "with poison". ;-)
Sorry that wasn't quite right. The Old English meaning didn't persist into Middle English, and the modern meaning seems to have come from the Old Norse meaning (which could mean 'gift').
@marmot Although that's a backwards etymology. I.e., Mitgift preserves the non-poison meaning, and only now people think it's literally 'with poison'.
@marmot Sorry that's what you said, basically.
@marmot I wonder how that change happened. It's an interesting cultural effect.
@marmot I don't know enough about gender in compound nouns. In Dutch 'gift' is feminine and 'gif(t)' (poison) is neuter. So both seem to exist with the gender distinguishing them.
@AlanMunn Actually I was joking. Nobody understands German genders. Trees, which you like so much, translates to "der Baum" (male), but a birch tree is "die Birke" (female). Very logical, isn't it?
@AlanMunn OK, now I understand why that's a science. (Just kidding ;-) (I just know that these genders are one of the greatest challenges when learning that language.)
@marmot Apparently it's very simple: (golden) marmot calls reflect perceived risk to the marmot: fewer notes in greater perceived risk. They may also encode properties of the individual (sex, age). Just down the road from you. blumsteinlab.eeb.ucla.edu
@AlanMunn Oh yes, I know that link very well. And he does his field work in very close to Aspen, which I really love and where I will be soon. (But I will try to avoid Gothic, not that he puts me in a cage. ;-)
@AlanMunn This was interesting. In Norwegian, too, “gift” means “poison”. But “gift” can also be an adjective, and then it means “married”. Many bad jokes were built on this foundation. We also have the word “medgift”, which, like the German “Mitgift”, means “dowry”.
Sorry for just shouting into the crowd again. If you have a second, could you perhaps kindly check if the link to the image is broken as it is claimed here?