I have the following problem. I'm creating a table using the longtable package since it will have more rows than the ones I'm upoading here in the example. However, some text as in the second row ignore text wrapping and stays over the rest of the cells next to it. So that's why I would like to k...
it doesn't actually cause any issue in this particular case, but it would be confusing if, say, >\centering p{2cm} was >\raggedright or p{\textwidth} or something.
@cfr 1980's memory constraints. Most similar options don't (or didn't) check eg \parbox[rubbish]{5cm}{hello world} gives no error, although we have since added a check to floats as \begin{figure}[H] meaning "move all floats to the end of the document" if you hadn't defined H seemed bad so now you get an unknown float option error,
@cfr but I could add a check now, you can probably afford half a dozen bytes of token memory
@PabloGonzálezL Ahh, I think I got the point, @DavidCarlisle and @UlrikeFischer: Loading \DocumentMetadata as done in the MWE provided moves the footnote from the page's bottom up to directly under the text block. (which one could mistake for the effects a \footnote inside a minipage has)
Is there a good practice to pass truch to a \cs_new:Npn defined macro? Basically it is like an s arg but for an internal macro. It needs to do something extra if an arg is true. I was thinking about just passing \c_true/false_bool and test it with \bool_if:NTF. Just wondering if this isn't anything nicer.
@daleif looks about right, then if you ever add a document level interface, you just need to pass the token generated by the s arg straight to the underlying expl3 command
@AlanMunn what was actually in the file? by pasting here you convert to utf-8 â but if the original was latin 1 with byte sequence E2 80 93 then that is the UTF-8 encoding of U+2013 endash – the byte sequence for UTF-8 U+00E2 U+0080 U+0093 is C3 A2 C2 80 C2 93
@DavidCarlisle that's what I'm already doing with certain user commands. This was just internal. I know the original was implemented using the 00 vs 01 test.
@DavidCarlisle I think that's exactly the problem. When BibDesk retrieves the record from the DOI server it makes an incorrect guess about the encoding. Why the server isn't only serving UTF-8 is unclear to me.
@AlanMunn the endash is being generated as utf-8 it's whatever you are then processing it with has interpreted it as latin1 which then got recoded as utf-8 so double encoded (which is the most common reason for seeing accented a: you see same in normal latex text if you use utf8 text and add \usepackage[latin1]{inputenc}
