Hey @DavidCarlisle... how many answers of yours doesn't also contain a complete duplicate comment (or comments) to the original question? ;)

@DavidCarlisle 北京烤鸭 ... looks about right, but the slower you roast the duck, the better it will become ...

Thank you, @JasperHabicht. :)

Missing character: There is no + in font nullfont!
Missing character: There is no + in font nullfont!
Missing character: There is no ( in font nullfont!
Missing character: There is no 1 in font nullfont!
Missing character: There is no 0 in font nullfont!
Missing character: There is no p in font nullfont!
Missing character: There is no t in font nullfont!
Missing character: There is no , in font nullfont!
Missing character: There is no 0 in font nullfont!
Missing character: There is no p in font nullfont!

@daleif ^^

@cfr exactly, Here is the more fun one from my doc

Message too long, I'll remove all the missing ... stuff

(PGFMath)PackagePGFMathError:Couldnotparseinput''asafloatingpointnumber,sorry.Theunreadablepartwasnear''.(in'x')SeethePGFMathpackagedocumentationforexplanation.(PGFMath)PackagePGFMathError:Couldnotparseinput''asafloatingpointnumber,sorry.Theunreadablepartwasnear''.(in'x')SeethePGFMathpackagedocumentationforexplanation.

One char at the time

I think someone might be interested in this thread forum.glyphsapp.com/t/…

@daleif you have a warped concept of fun ;).

@Werner well if the OP says that a comment fully answers there question, copying the comment (or sometimes moving it) seems the right thing to do

@JasperHabicht we should test that wih @PauloCereda

@خالدحسني ah so we can blame marcel unless it comes from the context code when we can blame @mickep (as hans isn't here)

@خالدحسني I quoted you in a comment yesterday, I'm not sure if it's reasonable to stretch in both directions? tex.stackexchange.com/questions/736081/…

It's palindrome day! ;-)

@Rmano you need 10 more silver badges.

Yes. I tried the necromancer yesterday...

@DavidCarlisle Seems to work in ConTeXt.

@mickep also in context mkiv?

@UlrikeFischer yes

@DavidCarlisle There is a PR github.com/latex3/luaotfload/pull/299 and it looks like it comes from ConTeXt code

@DavidCarlisle Some people want \sum to stretch horizontally, so a font designed this way would have it grow vertically (for display size) as well as horizontally.

@خالدحسني yes thanks I got the PR seems like just a setting missing?

@خالدحسني yes that's what they want, what i wasn't sure about was whether they have any chance of that working expecially if you get to the range where you are building things with extension glyphs, can you do that in two directions?

@DavidCarlisle It is a bit complicated. HarfBuzz, DirectWrite, etc, will set the advance width of mark glyphs to zero regardless of the advance set in the font (and many fonts depend on that), but not for all scripts. For some Indic scripts the width of marks is respected (though, I don’t remember which ones, and the node shaper might not support them anyway).

@DavidCarlisle I don’t know any implementation that support this. May be it is possible at some current implementations, but I never tried it. My recollection is that implementations either grow glyphs vertically (anything bug accents) or horizontally (accents)

@خالدحسني That's what I'd expect:-) thanks

@DavidCarlisle I'm not sure why the pr claims that that works, imho we are not using the reference font loader.

@UlrikeFischer first rule of tex support:-)

meanwhile:

texlive.net/…

@DavidCarlisle It seems that this sets the width of marks in general. But is this a good approach? Shouldn't the font decide about the widths of gyphs (including marks)?

But I am no font guy, so this is just a random thought

Latest l3kernel update with CTAN - should be working again with ConTeXt LMTX

@JosephWright How new version do you actually use?

@mickep The one in TL of course

(And yes, I know Hans doesn't really do CTAN releases so this lags behind, but TL is the base for testing for LaTeX)

@JosephWright Oh, OK, makes sense.

@JosephWright Can you use expl3 with ConTeXt? Not that I know much about ConTeXt at all ...

@JasperHabicht Yes, we set up a generic loader some time ago - due to the changes in the backend, the draw stuff etc. doesn't work, but basic ideas like loops, expansion control, etc., should

@JosephWright So, the loader more or less defines the basic expl3 functions for ConTeXt and then loads all the rest? So, this would mean that packages written in expl3 would also run in ConTeXt (with a wrapper, I guess)?

@JasperHabicht That's the plan, yes - I'd added a very simple test to our rig, so we know at least \fp_eval:n works :)

@JasperHabicht github.com/latex3/latex3/blob/develop/l3kernel/…

@JosephWright Haha, okay. That's at least something

@DavidCarlisle What I'm getting at is that you should just consider answering the question outright if you feel it would answer the question. The question comments do get messy with conversations, follow-up questions and thank-yous, that is difficult to clean up. If you convert a comment into an answer, attempt to clean up the comments, even flagging those you think should be removed. Just a suggestion really...

I know Microsoft wants to control everything, but my classroom too?

@AlanMunn :)

@Werner yes I remove comments unless it would make the other comments nonsense (although if you are going to delete them anyway I guess that doesn't matter) I very rarely post an answer without testing the code so if i don't have time to do that or the question isn't clear and i just guess (as I think happened in this one) I'll usually just comment, but then if the OP says it answered the question...

@AlanMunn lol

@DavidCarlisle Good good. Keep on guessing!

@AlanMunn does that mean you need MFA to login to rooms?

@cfr We've not - they tried it but we have a real issue with phone signal so it wasn't realistic

is showframe expected to change the page layout?

@JosephWright I guess you mean PC login ...?

@cfr Indeed

@cfr if you not explicitly set a paper size it loads letter, iirc.

@JosephWright you don't have the joys of electronic locks on doors ... (not actually MFA ... yet)

@Skillmon thanks. that is annoying.

@cfr we had, wasn't that bad. The most annoying thing was that I still needed normal keys for other rooms, so I ended up having an electric key and a bunch of normal ones.

@Skillmon yes, I have the same. but not the most annoying thing. the most annoying things: (1) we couldn't lock our office door for weeks because they removed the old lock without installing the new one and (2) when something goes wrong, you are screwed. so I ended up with no dinner because my food was in a fridge behind an electronically locked door not even security could open. we have a similar system for printing/copying and nobody could login for a week ....

Oh no. Error ... one of those where I don't even know where to start searching for the reason ...

@JasperHabicht Did you get "I'm broken. Please show this to someone who can fix me."?

@mickep No, I get a strange cs not defined, which only appears inside ExplSyntaxOn and only with one of two commands which I would say are not that different ...

seems to be a scoping issue, I guess

I want to pin that down first ...

@mickep No, it is not that grave ...

No error on Overleaf

Okay, let's disasseble this function until it works again ...

Okay, I think I won't be able to get this ... it only errs if the command is called inside ExplSyntaxOn/Off ... has something changed there in the last year?

@JasperHabicht maybe your command is using \scantokens?

@Skillmon In which way could this be a problem?

Hm, I am even unsure how to describe what happens ... I built a command where the user can input custom code (like an inline function) that will be repeated as often as there are items in an array and sets #1 to the index. The error appears if I insert as inline function \prop_item:Nn to access the relevant item from the array. I don't think that I use \scantokens at this point

Strangely, if I use another command that actually uses \tl_rescan:nn, things work. So, maybe it is indeed related

@JasperHabicht \scantokens reads the contents back in whichever category code regime is active at the time, since \ExplSyntaxOn is noticeably different to normal catcodes this is bound to behave differently.

@JasperHabicht etoolbox's patching commands are also affected.

@JasperHabicht you could try to create an MWE...

@Skillmon Well, the problem with an MWE is that it will be large, I fear

I need to boil down a complete package to just an MWE

@JasperHabicht is your package code available on GH?

github.com/jasperhabicht/jsonparse/issues/46

Yes

in the docs for ltproperties, this code is given as an example:

\tex_savepos:D
\property_record:nn{myposition}{xpos,ypos}
\tex_savepos:D

@JasperHabicht also doesn't break if \JSONParseArrayMapInline isn't used but only \JSONParseExpandableValue

what is the reason for the second \tex_savepos:D? latexdef says it is just \pdfsavepos, which wouldn't need the second as far as I know (at least with pdftex)?

@Skillmon Right. JSONParseExpandableValue is only \prop_item:Nn.

@JasperHabicht well \prop_item:Ne, but yes.

@Skillmon In the end, at least in my head, it should boil down to \cs_new:Npn \my_inline_function: { \prop_item:Ne \myprop {a[0]} } \int_step_function:nnN { 0 } { 1 } \my_inline_function: ... but this does not fail.

@JasperHabicht small aside: Your package uses user specified macro names which don't match naming conventions of L3 as direct l3prop variables.

You also assume that an l3prop variable is a valid tl

@Skillmon You mean things like \JSONParseArrayValue?

@JasperHabicht \JSONParseExpandableValue\mydata{a[0]} expands to \prop_item:Ne \mydata { a[0] }, \mydata is not a valid prop-name.

@Skillmon I see. Yes.

Well, there is always room for improvement from the syntax point of view. But I didn't want to make things too complicated. Also, I wanted to have an expandable command here.

@JasperHabicht the following compiles without error (but is still not entirely correct):

\documentclass{article}
\usepackage{jsonparse}

\begin{document}

\JSONParse{\myprop}{ { "a" : [ "b" , "c" ] } }

\ExplSyntaxOn

\RenewDocumentCommand { \JSONParseArrayMapInline } { m m +m } {
  \__jsonparse_warning_undefined_prop:N #1
  \cs_gset:Npn \__jsonparse_array_map_inline:n ##1 {#3}
  \group_begin:
    \tl_set_eq:NN \l__jsonparse_temp_tl #1
    \jsonparse_filter:Nn \l__jsonparse_temp_tl {#2}
    \jsonparse_array_count:NN \l__jsonparse_temp_tl \l__jsonparse_array_count_int
    \bool_if:NT \l__jsonparse_zero_based_bool {

@JasperHabicht nothing wrong with expandable commands. Your package has more severe coding issues, imho.

@Skillmon :nnN when the second argument is a V, because of the \exp_args?

@Skillmon =3 I am sure of that

@JasperHabicht \exp_args:NNnV will already have expanded \l__jsonparse_array_count_int so what \int_step_function:nnN sees is { \bool_if:NTF ... } { 1 } __jsonparse_array_map_inline:n, so two n`-type arguments.

@JasperHabicht also \int_step_function:nVN should (almost) never be necessary, since the second argument accepts an int expr, so it'll expand integer counters itself.

@Skillmon Alright, I understand. So, maybe I just did not understand fully how the meaning of f expansion. I probably should avoid this altogether

@JasperHabicht The problem is that \int_step_function:nnN is only restricted expandable, so f-expansion might not do what you intend it to do in edge cases. See interface3.pdf page 6 paragraph "Restricted expandable functions"

@JasperHabicht and yes, f is basically a leftover from the past, you seldomly need it.

@JasperHabicht in \JSONParseArrayMapInline you're using \tl_set_eq:NN on a #2 that's basically always a prop. You should use \prop_set_eq:NN instead and use a different variable, for instance \prop_new:N \l__jsonparse_tempb_prop and then \prop_set_eq:NN \l__jsonparse_tempb_prop #1 there.

@Skillmon That's true

@JasperHabicht please note that a prop not necessarily is a single macro that's tl-compatible. In fact the current version of l3prop supports two different data models in the implementation, one of which is absolutely unlike a tl. You should never rely on the implementation of any data type in L3 to look like another variable type.

@JasperHabicht \JSONParseFilter is broken as well, it also uses \exp_last_unbraced:Nfthis time on \tl_set:NV. It's an implementation detail (the way variants are handled) that makes this work. You should change its definition to:

\NewDocumentCommand { \JSONParseFilter } { m m m } {
  \__jsonparse_warning_undefined_prop:N #2
  \group_begin:
    \tl_set_eq:NN \l__jsonparse_temp_tl #2
    \jsonparse_filter:Nn \l__jsonparse_temp_tl {#3}
    \exp_args:NNNV
  \group_end:
  \tl_set:Nn #1 \l__jsonparse_temp_tl
}

This is essentially true for all 4 of your \exp_last_unbraced:Nf usages.

@Skillmon Yes, I know that one should not mix data types. But I have to admit that I thought that in the end everything is a token list ... But well, in the cases you pointed out, it is in fact wrong to use _tl when it is a prop really

@Skillmon Yup. I was about to refactor these. Thanks for the help!

@JasperHabicht you're welcome :)

I am sure that there is even more which needs improvement

@JasperHabicht please don't feel down because of my nagging, that's not my intention.

@Skillmon No, I don't! Actually, what you said is totally legit and I also found now that it is bad anyways to use a TL (even a "temp" one) at different places ... I recently saw this in another package and thought that this was bad practice. Now you pointed me to my own package =D

Ein jeder kehr vor seiner Tür ...

@JasperHabicht "Wer von euch ohne Bad-Practice ist, eröffne das erste Ticket" or something like that.

@Skillmon Yeah

I just know that I sometimes sound harsh when giving well meant critique because I just state whatever I spot, but I really don't mean it harshly.

Welcome to a new episode of AllTheDiff for easybook, I might have missed a few releases, so this is the comparison for the TL package revisions 73534 -> 73603! Let's dive right into it: easybook.tex (the documentation) got a new version with two \items! Also some documentation regarding imakeidx was changed to reference indextools instead accompanied by a whole paragraph being changed. [...]

There was quite some movement in easybase.sty as well, a variable was renamed and its default value changed to reflect the switch from imakeidx to indextools. The \listnumberline macro was changed to check whether \caption@labelformat results in a blank tl and if so output nothing. [...]

A new variant \str_if_eq:xnTF gets defined. \RegisterTitleIfname got an incompatible change, accepting an optional and two mandatory arguments instead of just a single mandatory one, this was seemingly done to support indextools here. [...]

A new macro \RegisterCapIfname is defined that's a shorthand for \RegisterTitleIfname. Some hook executed at the end of imakeidx got adapted to be at the end of indextools.

Wow, that was quite unexpectedly much text to type for this episode of AllTheDiff. Be sure to tune back in next time, when it's time to see what changed in easybook!

@Skillmon :)

@JosephWright this time the changes were actually hard to grasp while not trying to understand any of the code...