« first day (4935 days earlier)      last day (294 days later) » 

cis
cis
05:41
@DavidCarlisle Oha... "Noto Emoji" is as to my knowlegde a bitmap font. We need vectors - in all cases.

@AlanMunn Yes, I tried "Fontlab 8" right now.

TwemojiMozilla.ttf is a ttf-colorfont with vector-graphics which we can find in TexLive.

But there is a problem:
1) If I open TwemojiMozilla.ttf in Fontlab 8, I can export a copy an he makes TwemojiMozilla.ttf.

2) But if I add a own svg-graphic he exports two fonts
TwemojiMozilla.ttf (where tha added char does not work) and TwemojiMozilla-SVG.ttf
06:24
@cis I think this is because (also see my answer to your question on the site) TwemojiMozilla is not an SVG font. Maybe you need to convert the SVG glyph first so that it is included in the COLR/CPAL tables of the font? But I can only speculate ...
06:58
@UlrikeFischer Indeed: issue coming up in that area
 
1 hour later…
08:23
@WillRobertson looks as if the language handling is still not correct ;-(
08:39
@cis You could have a look at github.com/adobe-type-tools/afdko or github.com/fonttools/fonttools . I grabbed a copy of each at some point when I was having a deep-dive into fonts, but haven't had much of a play, so I don't know if they would be suitable or useful at all. But they may have different purposes/problems than FontForge.
AFDKO takes post-script as some of the input, and produces OpenType fonts. Fonttools is a collection of scriptable things to manipulate font files.
09:20
user image
4
Preparations ongoing. Bär got himself a hachimaki.
 
2 hours later…
11:41
@UlrikeFischer oh, you go to Japan?
12:32
@samcarter is v7.1.4 working for you?
@PauloCereda Yes, it is. I posted my macos version and java version on the gitlab issue
@samcarter thank you! <3
12:50
@PauloCereda If you need any other information to narrow down the problem, please let me know!
13:08
@samcarter thank yooou <3
13:52
@PauloCereda Hola don pato, same problem in windows (arara)
@PabloGonzálezL oh no, could you write something on the gitlab issue, please?
@PauloCereda Done!...Do you want me to try "openjdk"?
@PabloGonzálezL oh if you have it, it would help us tons
@PabloGonzálezL I am doing another test here, so any details you can provide, it will be super useful, thanks!
@PauloCereda Give me a few minutes to configure
C:\Users\pablg>java -version
openjdk version "21" 2023-09-19
OpenJDK Runtime Environment (build 21+35-2513)
OpenJDK 64-Bit Server VM (build 21+35-2513, mixed mode, sharing)

C:\Users\pablg>arara test.tex
  __ _ _ __ __ _ _ __ __ _
 / _` | '__/ _` | '__/ _` |
| (_| | | | (_| | | | (_| |
 \__,_|_|  \__,_|_|  \__,_|

Processing "test.tex" (size: 82 B, last modified: 2024-05-05
13:49:14), please wait.

(PDFLaTeX) PDFLaTeX engine .............................. SUCCESS

Total: 1.141 seconds
Ohhhhhhhhhhhhhhhhhhhh que pasó aqui
C:\Users\pablg>java -version
java version "1.8.0_401"
Java(TM) SE Runtime Environment (build 1.8.0_401-b10)
Java HotSpot(TM) 64-Bit Server VM (build 25.401-b10, mixed mode)

C:\Users\pablg>arara test.tex
  __ _ _ __ __ _ _ __ __ _
 / _` | '__/ _` | '__/ _` |
| (_| | | | (_| | | | (_| |
 \__,_|_|  \__,_|_|  \__,_|

Exception in thread "main" java.lang.NoSuchMethodError: java.util.List.removeFirst()Ljava/lang/Object;
        at org.islandoftex.arara.core.dependencies.Graph.kahn(Graph.kt:62)
        at org.islandoftex.arara.core.session.LinearExecutor.execute(LinearExecutor.kt:68)
@PauloCereda You are the java expert...I understand that openjdk and java(sun?) are the same thing.
@JosephWright What is the criteria for adding variants to base functions by the LaTeX team?
14:35
@PabloGonzálezL they should be. Given the message, the method is not available. Let me try something, could you test it for me?
@PauloCereda Yes, no problem :D
14:56
@PabloGonzálezL 'Striking a balance' - in many ways we'd like to add all possible variants, but that's unrealistic and also doesn't help then they are not needed (e.g. \int_eval:n doesn't really need an e-type version)
@PabloGonzálezL Over time we will only go one way, so do say what's missing
@JosephWright For example \cs_generate_variant:Nn \prop_gput_if_not_in:Nnn {NeV} (fontspec)
@JosephWright and { cen } (used by me :D)
@PabloGonzálezL Like I say, balance: these more esoteric variants are a bit tricky, as we want to add stuff systematically to some extent (e.g. here if you want NeV you really need to add Ne, ce, ceV, etc. - there's an issue with combinatorial explosion)
@PabloGonzálezL As we spot stuff used in multiple places 'in the wild', we do try to add to the core
@PabloGonzálezL PRs most welcome :)
@JosephWright Ok, I get it, the variant with e for the second argument makes pretty good sense to me.
@JosephWright     \prop_gput_if_not_in:cen { g__enumext_ \l__enumext_store_name_tl _prop }
      {
        \int_eval:n { \prop_count:c { g__enumext_ \l__enumext_store_name_tl _prop } + \c_one_int }
      }
      { #1 }
@JosephWright That's my use case for example
@PabloGonzálezL Use + 1 not \c_one_int ;)
@JosephWright Ouchhhhh...why?
15:07
@PabloGonzálezL I think the balance was that V-type for #2 is likely to be more common - there's an e-type for the standard \prop_put:Nnn base but the 'not in' ones have fewer variants
@JosephWright I think it is an equally valid choice to let programmers generate all the variants they need. Since a lot of variants where added only in the course of the last year (if I am not mistaken), I think it is good practice to generate these anyways ...
@PabloGonzálezL We decided a while ago that in general using constants here simply inhibits readability - the performance gain over the literal is tiny. We do need constants in a few places which is why they stay. (Things are different for fp ... more of an open question.)
@JasperHabicht Adding to the core doesn't prevent that - it's just a question of what's available out-of-the-box
@JosephWright Thanks :D
@JasperHabicht Certainly it will be a few years before all of the variants we provide can be seen as 'definitely there' across likely installs
15:10
@PabloGonzálezL could you try running this code on both JVM's in your machine? java -jar arara-test-issue.jar
@JosephWright Right. It is good to have some variants added. But then, I think you really need to think about what to include and what not, so finding the balance might not be easy ... (except you already have some kind of rule set up, which I don't know)
@PauloCereda C:\Users\pablg>java -version
java version "1.8.0_401"
Java(TM) SE Runtime Environment (build 1.8.0_401-b10)
Java HotSpot(TM) 64-Bit Server VM (build 25.401-b10, mixed mode)

C:\Users\pablg>java -jar arara-test-issue.jar test.tex
Running on Oracle Corporation (1.8.0_401)
Test list: [a, b, c]
Should remove first element: a

C:\Users\pablg>java -jar arara-test-issue.jar
Running on Oracle Corporation (1.8.0_401)
Test list: [a, b, c]
Should remove first element: a
@JasperHabicht Rules as they stand - no variants are removed, no new x-type ones will be added, new f-type also extremely unlikely to be added, in general we try to have a c-type for every N-type where the N is a variable (so \prop_put:Nen implies \prop_put:cen should be provides), in general give same coverage for local and global base functions (so \prop_gput:cen by the same logic)
@PauloCereda C:\Users\pablg>java -version
openjdk version "21" 2023-09-19
OpenJDK Runtime Environment (build 21+35-2513)
OpenJDK 64-Bit Server VM (build 21+35-2513, mixed mode, sharing)

C:\Users\pablg>java -jar arara-test-issue.jar test.tex
Running on Oracle Corporation (21)
Test list: [a, b, c]
Should remove first element: a
@JasperHabicht, @PabloGonzálezL We haver toyed with simply adding every possible for the 'current' variants - even with the combinatorial issue its not so bad - particular if you special-case things like \use:n and only have n- and e-type there. But it's not been a priority to look at
15:14
@JasperHabicht It is a matter of convenience and maintenance of documentation as such, if it is part of the core it simplifies things.
@PabloGonzálezL Yes, so any >1 use of a variant we are likely to add - one-offs are a bit tricky (but see comment about e.g. \int_eval:e not being required - there are some oddities out there)
@PabloGonzálezL strange... the stack trace talks about a non-existing method, yet...
@JosephWright Yeah, that's logical and good do understand. Also, I think, for programmers it is also a hint how to use the commands actually. If I see in interfaces that a certain variant exists, at least I feel I better understand how this command is supposed to be used. It offers a certain degree of security so to say.
@JosephWright Yes I think I read that in a LaTeX3 repo thread at some point and it makes sense.
@PauloCereda I just did the tests...my thing is to cook duck with potatoes :D
@PabloGonzálezL go away
15:20
@PabloGonzálezL Don't cook duck while testing TeX. I have a bad feeling about this combination ...
3
@JasperHabicht Jajajja
@JosephWright Question (I read it at some point), this would make sense to you as variant \int_gincr:e { g_some_ \g_tmpa_tl _int } ?
@PabloGonzálezL No, because \int_<whatever>:n are defined as evaluating their argument as an expression with expansion - n-type means 'does the documented thing with the tokens' not 'the tokens are never expanded at all', while a variant means 'expands the tokens then passes to the base function'
@JosephWright Now I understand why I have to use \tl_gset:Ne \g_tmpa_tl { foo } and then \ing_gincr:c { g_some_ \g_tmpa_tl _int }
@JosephWright I think I need to go through the documentation again :D
15:42
@PabloGonzálezL c already expands things, so depending on what you do, you might not need to do a \tl_set:Ne beforehand. For example, \int_new:c { g_some_ \int_eval:n { \g_tmpa_int + 2 } _int } would work (I think ...)
@JasperHabicht Yes it is true, but, in my case tl-var contains only a string (name of a prop-list) and the variable int var is associated to this one
@PabloGonzálezL I see ...
15:58
@JasperHabicht Anyway in this case it's not complicated to write your own function to do the job...it's just that in the first instance I thought e would do the job for me :D
16:14
@mickep yes the PDF week is in Tokyo.
17:19
@UlrikeFischer Oh, nice! I'd love to go to Japan one day. Have fun!
18:09
Hi All, I think I met a situation where l3build check is tricked by something it does, but shouldn't. I'm probably doing something wrong too but, as far as I can tell, l3build is behaving inconsistently. I could not isolate the issue, so I probably don't have enough for a proper report. Anyone willing to take a look at a specific test file? If so, I can share more details.
cis
cis
Yes, unfortunately I don't know how to assign the "COLR/CPAL palette" to a (colored) SVG graphic in 'FontForge' or 'Fontlab 8'.
I can't figure it out from the googled instructions.

If anyone knows this offhand, I can easily send an example graphic in svg format (or original ai format).
@PabloGonzálezL yay, one Engineer more in the world!
Is there a TeX way to get the name of a control sequence, like if the cs is \foo get foo? More or less the reverse of \csname?
Oh, just \cs_to_str:N I assume ...
18:27
@Skillmon Jejje :D
@PauloCereda I'll be offline for a while, but stay tuned for anything.
cis
cis
19:03
@Skillmon @Skillmon
19:39
@UlrikeFischer -- Do have fun! When Gordon and I were there for the TUG meeting, we discovered a very nice ice cream shop in the Shibuya complex. The first time I'd ever tasted cranberry ice cream. I'm used to all sorts of cranberry edibles (we live in New England, after all), but never ice cream. (It was quite good.)
19:57
@JasperHabicht Yes, nice and robust: if you are LuaTeX-only there is a primitive \csstring
20:11
@cis svg fonts don't have a COLR table, if you have an svg table you can specify colour that way can't you?
20:23
@PabloGonzálezL we figured out what happened, thanks for the feedback. :) I have some sort of fix, but I need @TeXnician's review and approval because it's really a workaround. See the thread, I wrote something about it there. :)
@PauloCereda Great, I read the thread in gitlab...one minor thing...can you update man arara?
@PabloGonzálezL oh anything in particular?
@PauloCereda --generate-completion
@PauloCereda --whole-file mmm and remove --header?
@PabloGonzálezL ouch, thanks for spotting that! We will def update that.
20:40
@PauloCereda I think I'm one of the few who use man nowadays :(
@PabloGonzálezL I think it's been a while since our manpage is outdated!
@PauloCereda Ohhhhhh sí :D
21:03
Is there any way to copy \@currenvir using expl3? something along the lines of \cs_new_eq:??. I would like to use \str_case:en { \cs_currenvir } { code } in the form \str_case:en { \my_currenvir: } { code }
Or any ideas on how to mimic \@currenvir in expl3 for two environments of which I have control in defining them?
21:58
@PabloGonzálezL why can't you just test \@currenvir directly but you could copy it with \let or \cs_new_eq:NN as you say
@PabloGonzálezL but I'd say it's logically a local variable so \l_my_currenvir_tl not \my_currenvir:
@PabloGonzálezL It's a 2e concept: as @DavidCarlisle says, just use the current name
22:16
@PabloGonzálezL even if you define an L3 name for some use you'd still have to define \@currenvir (or rather, \begin will define it for your environments anyway)
22:37
@DavidCarlisle Ok, I understand, I currently have it straightforward, I just wanted to get rid (as much as possible) of using @ in the code... snif
@PabloGonzálezL well since you are e expanding anyway you can have a fixed \tl_new:Nn\l_my_currenvir_tl{\@currenvir} and compare \l_my_currenvir_tl if you prefer since it will e expand to the e expansion of \@currenvir
@DavidCarlisle I like that...what is the preference here _tl or _str?
23:20
@PabloGonzálezL it can't be a str if its definition is \@currenvir

« first day (4935 days earlier)      last day (294 days later) »