TeX, LaTeX and Friends - 2019-05-06

« first day (3109 days earlier) ← previous day next day → last day (1827 days later) »

1:24 AM

@PauloCereda What do you mean "nothing was gained from it"? It kept several people busy for a while. Isn't underemployment the challenge of modern society? ;-)

3 hours later…

4:16 AM

@egreg as far I know you really like enjoying answer regexp questions, and here you have a question and answer to find a regexp from a statement (in math.SE)!: math.stackexchange.com/q/3212670/525384 Are you agree with the answer? Thanks!

3 hours later…

7:04 AM

@JosephWright That's good news. However I got the update only for win32. On linux-x86, I am still getting: This is dvipdfmx Version 20190225 by the DVIPDFMx project team

@AlexG Probably because Akira builds like every day, whereas other people don't

@JosephWright Thus, binaries are not centrally built?

But only on the platform the upstream developper prefers?

@AlexG No, Karl has a team of people; mostly they take one platform each

@JosephWright Do you think an e-mail to tex-live might put in a bit momentum?

@AlexG Might want to check the list they have for builds: there is a dedciated one

7:09 AM

@JosephWright Ok. Where can I find it?

@AlexG tug.org/mailman/listinfo/tlbuild

@JosephWright Thank you! I am going to subscribe.

@JosephWright Other question, are dvipdfmx and xdvipdfmx unified (again)? Or are they maintained by different people?

@AlexG They are unified: makes life a lot easier (there's just the image inclusion stuff that is better in xdvipdfmx I think)

@JosephWright That's good. BTW I saw you invitation to the dvipdfmx mailing list. I remember there has existed one already at dvipdfmx@ktug.or.kr

@AlexG I guess the old one is defunct: none of the current devs are on it

7:24 AM

@JosephWright Yes, ChoF seems to be inactive for quite a while now. (Although I saw him dropping in here recently.)The sources on the original home-page are from 2011 or so.

@AlexG any thoughts about my issue with the form fields?

@UlrikeFischer Good morning! Not yet, but going to look at it today.

@AlexG thanks and good morning too!

7:42 AM

4:40 in the morning right now. :)

@AlexG the newest xdvipdfmx is broken ;-(. tex.stackexchange.com/q/489370/2388

@UlrikeFischer oh no

8:01 AM

@UlrikeFischer Thank you for reporting the issue.

@AlexG it looks rather urgent if all sort of math fonts suddenly fail ...

8:22 AM

@UlrikeFischer Are there special requirements (eg some development version of L3 pkgs) in order to run the testing code you provided?

@AlexG I've just done a release, but you might want the 'burning edge' expl3: @UlrikeFischer works on higher level stuff, I do drivers, ...

@AlexG well the \driver commands need a rather recent expl3, but it should work with a texlive version (and they should not be essential to reproduce the problem anyway). But I had a development expl3 active when trying it out, if you can't reproduce the issue I will have to retest without it.

8:58 AM

@DavidCarlisle meanwhile, in the longtable alley... no bugs reported so far. :)

@PauloCereda naturally

@DavidCarlisle Just stumbled on an issue in the LuaTeX definition of \@ifundefined. What was the plan with:

\def\@ifundefined#1{%
  \ifcsname#1\endcsname
    \expandafter\ifx\lastnamedcs\relax\else\@ifundefin@d@i\fi
  \fi
  \@firstoftwo}

@DavidCarlisle I assume either \expandafter\ifx\csname lastnamedcs\endcsname\relax (er .. why) or just \ifundefined\lastnamedcs? I was testing an old LuaTeX and got an error here as it fails if \lastnamedcs is not defined

@JosephWright I'd have to check the records we had lots of discussion around the time we changed \@ifundefined to not leave \relax but all I can see on that luatex version is % Optimised version for Lua\TeX, using |\lastnamedcs| I'll have to check the email...

@JosephWright that version is guarded by \ifx\directlua\@undefined perhaps it would be better to test that \lastnamedcs was defined....

@DavidCarlisle Would be easier :)

@DavidCarlisle Probably of course I'm the only person going to go 'does expl3 still load with TL'09' and find this particular issue :)

@JosephWright lastnamedcs is a bit weird anyway i wonder if the optimisation is worth having a different code path

9:09 AM

@DavidCarlisle I read emacs in it

@DavidCarlisle I suspect not, at least for us in the way the kernel is set up; for Hans it's different

@JosephWright (sorry to jump in) you mean, for ConTeXt?

Hmm, counting up how many TeX systems I have installed: TL'09-TL'19 Windows native, MiKTeX 2.9, WSL TL'15, Ubuntu Trusty VM + vanilla TL, ConTeXt stand-alone ltmtex

Of course, when I had the Mac it was more impressive :)

@JosephWright show off :)

@PauloCereda Yes: he's go no engine variation to worry about

@PauloCereda I was looking at how full my disk is: I wish I'd got the 500Gb one

9:12 AM

@JosephWright rm -rf / and you can get a lot of space. :)

@JosephWright M has managed to fill a terrabyte hd and a 225 ssd in his laptop, and I don't think he has a single copy of tex installed...

@DavidCarlisle ooh

@DavidCarlisle :)

@JosephWright guess who suggested the luatex optimised version:-)

@DavidCarlisle I mean only that with a modern SSD I can't swap the HD for a bigger one ...

@DavidCarlisle That would be me I guess

9:18 AM

@JosephWright no , Bruno:-)

@DavidCarlisle Ah, right

@DavidCarlisle That does make sense

@JosephWright dd if=/dev/urandom of=myimportantfile.txt bs=1T count=1

Have fun. :)

You could use P instead of T for maximum fun.

@DavidCarlisle ^^

C:\Users\davidc>where dd
INFO: Could not find files for the given pattern(s).

@PauloCereda ^^^

@DavidCarlisle Phew, that would be bad

@DavidCarlisle I think @JosephWright ran the command and now his entire lab exploded...

Which would make perfect sense since chemistry labs should explode at a certain point...

What's the point of being a chemist if you cannot explode things once in a while? :)

@PauloCereda you could be a physicist and explode smaller things with bigger bangs

2

9:28 AM

@DavidCarlisle OOH THAT'S A FANTASTIC PLAN

@PauloCereda er no, it's a really bad plan, there are world treaties to discourage it.

@DavidCarlisle oh

@DavidCarlisle what if my future self travels back in time to warn me about my current self to not explode things?

@PauloCereda then you would find that you are just a character in a scifi novel and not a real duck at all

@DavidCarlisle oh no

/quacks in despair

@DavidCarlisle more of a sitcom instead of a scifi novel. :)

Harald Hanche-Olsen

9:53 AM

@DavidCarlisle Dioxygen difluoride sounds like a real fun substance to play with, though. @PauloCereda

@HaraldHanche-Olsen ooh

@HaraldHanche-Olsen stick to mathematics

Harald Hanche-Olsen

@DavidCarlisle Every time I think I should do some real work in the real world, I dig up that blog post … and the urge goes away.

10:11 AM

@JosephWright , @UlrikeFischer Form Fields (Widget Annots) should not be broken across lines. Since every Widget must have a unique name, /T (<name>), Widgets broken across lines end up as multiple Annotations with the same name, leading to invalid PDF. Therefore, I would suggest not to provide \driver_pdf_field_begin:nnw ... \driver_pdf_field_end:. That way, if someone uses \pdfstartlink ... \pdfendlink to insert Form Fields, he will do this at his own risk.

10:23 AM

@AlexG we changed that already. the field-version is gone again. And \driver_pdf_link_begin_user:nnw no longer adds /Subtype/Link, so it can also be used with /Subtype /Widget (if someone wants to risk it ..). hyperref uses \pdfstartlink here, but the content is imho always boxed (but I will check).

@UlrikeFischer Thanks for the clarification!

@UlrikeFischer , @JosephWright Do you provide something like \pbs_appendtofields:n, that allows a user to add an annotation object reference to the /AcroForm's -> /Fields [...] array?

@AlexG I'm just reviewing all the keys in the catalog to decide which one need which management tools. I have already been wondering about /AcroForm. I found coolcooltips, pdfnotiz, pdfbase and hyperref using it until now. Do you have thoughts about what cooperation is needed here and what happens if they all add something to /Fields?

10:50 AM

@UlrikeFischer I have the impression that interactive /Widgets must be registered (referenced) in this array in order to be functional. In particular, they must be listed there in order to be found by JavaScript (object doc method getField(<field name>) , as in my animate package. Thus it would be very nice to have such a hook. Otherwise LaTeX packages trying to write to /AcroForm <</Fields [...]>> on their own might compete with each other.

@AlexG that something must be there is clear, I'm only wondering what exactly (e.g. the reference seems to imply that only "root" fields should be there) and how to organize it. If you want to take a look (work in progress ... github.com/latex3/pdfresources/blob/testlinkstuff/…)

11:09 AM

@UlrikeFischer Don't know either. Root fields do not need to have child fields. With animate, all Widgets belonging to one animation (anim frames and controls buttons) are root fields and registered all in the /Fields array of the /AcroForm dictionary (To be addressable via JavaScript:

I have just read in the PDF spec that child fields do not need a /T (...) entry and just share the same fully qualified name of their parent. Thus, Widgets broken across lines might be possible, after all. But how to create a parent Widget?

11:30 AM

@AlexG I guess some tests are needed here. Can you make a simple (e.g. with only 2 frames) animate example (it should need some javascript)? I will then add hyperref and look what happens.

11:52 AM

@UlrikeFischer I experimented a bit with animate. Animations, including control buttons, are functional, if I simply add /AcroForm << /NeedAppearances true >> to the /Catalog without any reference to Widgets.

Need to test what other viewer say, e. .g Foxit.

@AlexG and what happens if you add a Form-Field with hyperref?

user image

@JosephWright ^^ one only need not to look at mails for a few hours and you reimplement all atbegshi ;-).

@UlrikeFischer /TextField ref, for example, is added to //Fields, but the animate-related Widgets are missing. hyperref seems to win the race. Here is something for you to experiment with:

\documentclass{article}
\usepackage{animate}

\begin{document}

  Animation:
  \begin{animateinline}[controls]{1}
    \fbox{\Huge 0}
  \newframe
    \fbox{\Huge 1}
  \end{animateinline}

\end{document}

12:11 PM

@UlrikeFischer Foxit is very tolerant. The animation works even if the /AcroForm dictionary is removed completely.

@UlrikeFischer At the DANTE meeting you mentioned that you have the PDF 2.0 standard. Where did you get it? Especially do you know a cheaper store that the bsi? (It costs £126.00 there, that's a bit over my budget)

@MarcelKrüger Dante paid it for me (and they also got it, on every page it says "Licensed to Dante e.V/Ulrike Fischer").

12:27 PM

@UlrikeFischer Thanks, then I will keep looking.

@MarcelKrüger do you need something special from it?

@UlrikeFischer Happy you, to own a copy. A similar discussion was going on recently on the Poppler mailing list. I am still using the 1.7 spec.

@AlexG Same here, though probably we both should talk to DANTE (or perhaps UK-TUG)

@JosephWright They don't know me. I am not a member of either.

@AlexG But you are making a big contribution, and for both you have a 'referee' (@UlrikeFischer for DANTE, me for UK-TUG)

I was looking at the install size of my TL archive: it turns out it's no so bad (around 50Gb): it's the VMs that push up usage

12:37 PM

@JosephWright Oh, it would be a great honour for me to be eligible for getting it.

@AlexG uk.tug.org/about/funding

@UlrikeFischer Not really, I am currently writing a PDF backend for LuaTeX in Lua, mainly to add some features without having to patch LuaTeX all the time and maybe even get LuaMetaTeX compatibility. Currently I am generating PDF up to 1.7 but I would like to support any new stuff too.

1:11 PM

@JosephWright Thank you for providing the link!

@MarcelKrüger wow, sounds interesting. And it is really quite a pain, that the standard is not better available.

1:41 PM

@JosephWright , @UlrikeFischer : Since the latest expl3 update I cannot compile anymore the following code via latex + dvipdfmx. dvitype on the intermediate DVI shows a lot of PostScript code, which causes dvipdfmx to fail. Also, the log file of the latex run indicates that l3dvips.def was loaded. As DVI is generated by latex , the dvipdfmx backend cannot be guessed. dvipdfmx should be added as a package option to expl3 (as pdfbase does, for example).

\documentclass[dvipdfmx]{article}
\usepackage{animate}

\begin{document}

  Animation:
  \begin{animateinline}[controls=false]{1}
    \fbox{\Huge 0}
  \newframe
    \fbox{\Huge 1}
  \end{animateinline}

\end{document}

@AlexG did that every work? Well perhaps it did when l3dvips didn't have so much postscript in it and so didn't harm, but to setup the correct expl3 driver you imho always needed \PassOptionsToPackage{driver=dvipdfmx}{expl3}. Beside this: package options are not really the solution. If expl3 should go in the kernel, the driver code must be loaded separatly in this case (we were discussing this a few days ago).

1:57 PM

@UlrikeFischer This has worked smoothly for more than 10 years. dvipdfmx as global documentclass option was forwarded to any package that needed to know about inserting the right specials (pdf: ... instead of ps: .... Now the PostScript code inserted by l3dvips breaks everything. BTW, when runningxelatex, l3dvips is not loaded. This should be the same if DVI is to be produced for the dvipdfmx backend. And also for dvisvgm.

@AlexG the option was never forwarded to expl3, your example run in texlive 2017 would load l3dvips too, you were only lucky that it didn't lead to errors. With xelatex there is no problem, as xelatex can be detected without problems. I think we will have to discuss how to handle this. Perhaps expl3 should accept at least dvipdfmx and dvisvgm as option too. @JosephWright

@UlrikeFischer @JosephWright But why should dvipdfmx get to process PostScript code that xdvipdfmx doesn't? Please provide l3dvipdfmx that is perhaps somehow derived from l3xdvipdfmx.

@AlexG that isn't the problem, none of the driver name options affect expl3, as the option there is driver=dvipdfmx not simply dvipdfmx. arguably animate should handle that by defining its dvipdfmx option to pass driver=dvipdfmx to expl3, but as @UlrikeFischer says, probably simpler if expl3 defines the "simple" options

@AlexG I think we are currently speaking of different things. The problem is simply that expl3 doesn't recognize the document option "dvipdfmx", it expects "driver=dvipdfmx".

2:19 PM

@DavidCarlisle @UlrikeFischer @JosephWright @DavidCarlisle In pdfbase I modelled dvipdfmx "detection" after graphicx and hyperref, which well evaluate a global dvipdfmx doc-class option.

So maybe simple driver options would be a good thing to add to expl3 (As David suggests)

@AlexG probably, even if you detect it correctly: if another package has already loaded expl3 the wrong driver has been loaded too. The only safe method would be if the user would add \PassOptionsToPackage{driver=dvipdfmx}{expl3} before documentclass

@JosephWright oh boy, UK-TUG funding woes :)

2:34 PM

@UlrikeFischer yes defining the simple name options in expl3 would improve that though

@UlrikeFischer Something that used to work for a long time and which complies with standard LaTeX user-level conventions, that is, passing "simple" driver options to the document class, should continue to work with expl3 loaded under the hood. In my opinion, LaTeX-input not starting with \documentclass should not be recommended practice (to the standard LaTeX user).

@AlexG well driver=dvipdfmx as documentclass option should work too. But I personnally don't like to use global options to much - with all the stuff e.g. KOMA is putting in there it is getting overcrowded, and all this options have to be handled by all packages.

@UlrikeFischer it doesn't though (I just tried)

@DavidCarlisle ups.

@DavidCarlisle who can we blame?

3

@UlrikeFischer @JosephWright (or me) depending who you blame for the expl3 keyval options and standard 2e options not quite tying up

2:41 PM

@DavidCarlisle missing keyval syntax for global options?

@DavidCarlisle ooh

@UlrikeFischer I didn't trace but the l3dvips file gets loaded

@DavidCarlisle yes saw it.

@UlrikeFischer @DavidCarlisle @JosephWright Currently I am using l3keys2e to define and evaluate key/val package options in my packages. But this already requires expl3 to be loaded. I would have to split package option processing in my packages, such that driver options are processed before loading expl3 (in order to be able to pass it as driver=whatever to expl3), and once expl3 and l3keys2e are loaded to process the remaining package options.

2:58 PM

@AlexG we quite agree. The driver is such a core, global option that it should be set before or at documentclass.

@UlrikeFischer Thank you,,:-) ! So, would you also agree to support "simple" driver options in expl3?

3:13 PM

@AlexG probably will be best, one slight complication is that we are half contemplating a version of expl3 preloaded in the format, in which case we'd need some (as yet undecided) way to delay the driver loading and offer some document level way to control that, so changing things here at a point where we expect more changes isn't great but the current behaviour isn't great either, so...

@DavidCarlisle even if I prefer a setup before documentclass (which will allow proper keyval), we will probably have to allow some setup in the global options too. Which means that driver loading will probably happen after the global options have been seen.

@DavidCarlisle Ah, I see. But thank you for your understanding! I am convinced you will find a good solution!

1 hour later…

4:38 PM

@AlexG dvipdfmx is for (u)pTeX, where it can be guessed ...

@AlexG The original aim with the options for expl3 was to be keyval and to explicitly ignore document class ones. They are at best rather ill-defined: are the options for the class or the document? At the same time, the driver is not (or should not) be part of the nature of the document, rather of the route used to create output.

@AlexG As such, @UlrikeFischer's suggestion of a pre-\documentclass option list is perhaps best, though arguably it should be set by having a specific binary for each case.

@AlexG Now, granted, realism may mean dealing with the existing, common, document class options, but really as a fall-back

@AlexG As already noted, we need to think about this area to deal with 'slipstreaming' into the format

@JosephWright what does a "specific binary" mean?

@UlrikeFischer Well, if you are creating an SVG you probably want svglatex or some such, don't you

@JosephWright you mean if people want to run latex + dvipdfmx there should be a binary latexdvipdfmx?

:5018517 I mean that to a first approximation, we can tell the driver from the command line (binary) except for dvisvgm: pdflatex/lualatex => pdfmode, (u)platex => dvipdfmx, latex => dvips, xelatex = > xdvipdfmx

@UlrikeFischer It would make life a lot easier :)

@UlrikeFischer That's just (u)platex

@UlrikeFischer Other than for pTeX-based engines, I don't see a reason to explicitly choose dvipdfmx over pdfmode

@UlrikeFischer Of course, as I say, realism means we need other ways of dealing with this. As @DavidCarlisle says, we likely do need to worry about \documentclass options, but should work out how we are going to handle loading from the format

@JosephWright yes, it would be easier, one wouldn't have to constantly change driver options in the document.

2 hours later…

6:30 PM

> Windows 10 is getting a new terminal for command-line users, Microsoft announced at its Build developer conference today. The new so-called "Windows Terminal" will launch in mid-June and promises to be a major update of the existing Windows Command Prompt and PowerShell experience. From a report: Indeed, it seems like the Terminal will essentially become the default environment for PowerShell, Command Prompt and Windows Subsystem for Linux users going forward. The new terminal will feature faster GPU-accelerated text rending and "emoji-rich" fonts, because everything these days needs to s…

@PauloCereda Link?

@JosephWright techcrunch.com/2019/05/06/windows-gets-a-new-terminal

> Microsoft is unveiling a number of new features for its upcoming Edge Chromium browser today. From a report: The first big addition is a new "IE Mode" for Edge that will allow businesses to load old sites directly in the new Edge Chromium browser, using the Internet Explorer rendering engine.

Welcome to the 90's!

6:46 PM

@PauloCereda because everything these days needs to support emojis lol

@AlanMunn :D

Coming soon, Windows 💩.

3

@AlanMunn LOL

7:26 PM

@JosephWright I am trying to cope with the new situation. It would be desirable if at least driver=<whatever>, given as doc-class option would be forwarded to expl3, such that drivers that cannot be auto-detected, namely dvipdfmx and dvisvgm, can be set-up appropriately. Moreover, it would be good if something like \sys_if_engine_dvipdfmx:TF and \sys_if_engine_dvisvgm:TF could be added to the existing tests.

@AlexG you can't test for dvipdfmx and dvisvgm. When latex is run you can't know that this drivers will be used, unless the user added a suitable setting in the document (that's one of the main problems with this drivers).

@UlrikeFischer I know this. Therefore I am asking for driver=dvipdfmx|dvisvgm as expl3 option.

7:47 PM

@AlexG you mean testing which option has been used? This should be possible (but it probably shouldn't be called \sys_...).

@AlexG well the problem is that expl3 currently ignores all of the document options, also because at the end it should be loaded before \documentclass. So one really need to think how to do it at best. Are you using dvipdfmx a lot?

@AlexG Those are not engines ....

@UlrikeFischer It probably is sys (run time stuff)

@AlexG We need some handling of options as already noted; I'm sure we'll cover it!

@JosephWright the variable is called \l__expl_driver_tl, and the value could be e.g. pdfmode, so it felt more like a driver variable to me, but if we implement your plan to build binaries for everything it could be sys ;-).

8:07 PM

user image

8:50 PM

@UlrikeFischer Usually pdflatex and latex+dvips+ps2pdf. It is just annyoing when things break.

@JosephWright : Do you think Shunsaku got my message I sent to the new dvipdfmx list?

@AlexG I think so

@JosephWright Fine.

@AlexG ;-). We were only wondering if someone actually use latex + dvipdfmx. I have been looking at the /Acroform question. It is quite clear that there is a conflict between hyperref, coolcooltips and pdfbase. One ends with two /AcroForm entries. But it is not quite clear why you and coolcooltips use this "interactive form dictionary"

@UlrikeFischer upTeX

@JosephWright I meant with the normal pdftex engine.

8:57 PM

@UlrikeFischer Got that

@UlrikeFischer animate's animations don't work if /AcroForm is missing.

@AlexG I wonder why exactly. Is the fields entry needed or only the NeedAppearances setting?

@UlrikeFischer Next are \mediabutton's inserted with media9. With:

/AcroForm
<<
   /NeedAppearances true
>>

AcroReader asks if I wouls like to save the document upon closing. This is annoying.

If I have:

/AcroForm
<<
/Fields 8 0 R
/NeedAppearances false
>>
They dont bother me with this question.

9:13 PM

@DavidCarlisle \ooalign strikes again. ;-)

@egreg tilde arrow?

@DavidCarlisle Bingo!

@egreg pale imitation of ⥲

@egreg "that is too sexy" ;-)

@UlrikeFischer first time @egreg's been described that way

9:18 PM

@UlrikeFischer LOL

@AlexG hyperref sets /NeedAppearances true when form fields are used, so one will have to decide who should win here ...

@AlexG btw: NeedAppearances is deprecated in pdf 2.0.

9:43 PM

@UlrikeFischer Handy having the ref.!

@JosephWright ;-). Doubles the pages to check ...

« first day (3109 days earlier) ← previous day next day → last day (1827 days later) »

Transcript for

May '196

$TeX - LaTeX$ TeX, LaTeX and Friends

\begin{chat}

join this room
about this room

00:00

06:00

12:00

18:00

all times are UTC

$TeX - LaTeX$

site design / logo © 2024 Stack Exchange Inc; legal

mobile