LaTeXML
LaTeXML copied to clipboard
orcidlink.sty binding
Fix #2386 partially. orcidlink.sty can be read raw (after adding \XeTeXLinkBox to hyperref), except that:
\fontcharhtis not implemented (yet?), so I temporarily redefine it with a hardcoded value- the logo needs resizing in CSS to match the browser font size, so the binding attach a class
Furthermore, the ORCiD logo does not actually resize and is misaligned because the @viewBox attribute is missing, but that will be solved once #2376 is fixed.
Would you be willing to also add a small test? Maybe at t/graphics/orcidlink.tex or similar.
And it can depend on the sty file having been installed in t/65_graphics.t:
latexml_tests("t/graphics",
requires=>{colors=>'dvipsnam.def',
xcolors=>'dvipsnam.def',
orcidlink=>'orcidlink.sty'});
Would you be willing to also add a small test? Maybe at
t/graphics/orcidlink.texor similar.
The test would hardcode the specific SVG produced by the current version of orcidlink. Would that cause problems in the future, should orcidlink modify the logo (unlikely!)?
Would you be willing to also add a small test? Maybe at
t/graphics/orcidlink.texor similar.The test would hardcode the specific SVG produced by the current version of orcidlink. Would that cause problems in the future, should orcidlink modify the logo (unlikely!)?
We may need to update it if/when such transitions happen, which shouldn't be too painful. Probably a small price to pay, so that we also get notified if some future internal change breaks the expected sty load.
Ok, the test is not feasible because TL2021 and later have different implementations. I have updated the binding to make the TL2021 version work, but I have found a major issue with all versions: when \orcidlink is used inside \author{}, LaTeXML omits the SVG colours and you only get a black disc. Not sure why! Converting to draft until somebody can fix it.
The testing harness already has a nice technique to specify a minimal texlive version. Checking this test only for the latest texlive should be fine. That is possible via:
requires=>{ #...
orcidlink => {packages => 'orcidlink.sty', texlive_min => 2021}}
Figuring out what happens in the \author case is definitely worth a debugging deep dive, especially since one would expect this is where most of the use will come in practice.
In earlier latexml decades I would even be tempted to suggest hardcoding the expected SVG in the Perl binding as a DefConstructor, to guarantee robustness. That used to be common when we had no other easy path forward. But best to check if the raw interpretation can't be fixed first. I'll try to take a look.
Since #2398 was closed by #2400, does that mean that this draft will work now?
@xworld21 I promise not to change that SVG code ;)
Ping @brucemiller / @xworld21 , anything else this orcidlink PR still needs before it can be merged?
I can't test this right now (and won't be able to for several weeks), but in principle it should work fine with the new patches.
Many things have changed though: does LaTeXML implement \fontcharht now? If so, the code can be simplified.
Since @duetosymmetry promises not to change the SVG, the PR could also be reimplemented by hardcoding the image. There may be copyright issues with LaTeXML being public domain, though.
If you think it would be helpful, I can email [email protected] and find out if there is any copyright issue. Most of the materials in ORCID’s Brand Library are under CC0 license (i.e. "no rights reserved"). The name and logo are not. They are trademarked. But I don't know what that implies about distribution, beyond what they say on their guidelines, "the logos [...] shall be used in accordance with these guidelines". Those guidelines don't say anything about re-distribution. The closest they get is saying "ORCID Logos and iD icons must be used as provided, and must not be changed or altered in any way."
I doubt copyright is a real issue here (it rarely is), but if it were, there is always the easy solution of bypassing the details of the asset generation and instead creating an element pointing to the official asset, as wtih:
https://orcid.org/assets/vectors/orcid.logo.icon.svg
@dginev That's a good point and good idea! Just for reference, I looked at INSPIRE, ADS, and the arXiv, all of which have the ORCID icon somewhere on their sites. They all serve the asset themselves, rather than pointing at a cross-site source (e.g. https://arxiv.org/icons/orcid_16x16.png , https://ui.adsabs.harvard.edu/styles/img/orcid-active.svg , and https://inspirehep.net/static/media/orcid.83064add.svg )
Regarding \fontcharht: That was essentially a hack to get the height of the logo to be the same as the capital height of the current font. Using height: 1cap; as @xworld21 implemented is actually cleaner in CSS than in LaTeX. AFAIK this is widely supported by browsers newer than 2023, see https://caniuse.com/mdn-css_types_length_cap .
BTW I started testing this and ran into the following issue. First, orcidlink.sty from v1.1.0 uses \ifstrempty which comes from etoolbox. However, I didn't explicitly write \RequirePackage{etoolbox}, because either hyperref or tikz or both load it. But LaTeXML didn't like \ifstrempty without RequirePackage('etoolbox'); in orcidlink.sty.ltxml.
Even after adding that, I still have a failure with a minimal tex file. Below I attach a zip file with the minimal test, the resulting pdf, the log file from LaTeXML, and the resulting xml. Here are the warnings/errors:
Warning:misdefined:\pgf@lib@svg@relative The conditional T_CS[\pgf@lib@svg@relative] is being defined but doesn't start with \if
at pgflibrarysvg.path.code.tex; line 67 col 0 - line 67 col 27
In Core::Definition::Primitive[\newif De... /localhome/leo/perl5/lib/perl5/LaTeXML/Engine/plain.pool.ltxml; line 240
0.56 sec) 0.57 sec) 0.64 sec) 12.81 sec)
ABD: EveryShipout initializing macros
Error:expected:{} Missing argument {} for Core::Definition::Expandable[\@secondoftwo {}{}]
at orcidlink.tex; line 7 col 0 - line 7 col 54
Ended at orcidlink.tex; line 7 col 0 - line 7 col 54
Input is empty
In Core::Definition::Expandable[\@second... /localhome/leo/perl5/lib/perl5/LaTeXML/Engine/LaTeX.pool.ltxml; line 5810
<= Core::Gullet[@0x55ae2ee8d820] <= Core::Stomach[@0x55ae2ee86630] <= Core::Definition::Primitive[Begin] <= ...
Error:expected:{} Missing argument {} for Core::Definition::Expandable[\@secondoftwo {}{}]
at orcidlink.tex; line 7 col 0 - line 7 col 54
Ended at orcidlink.tex; line 7 col 0 - line 7 col 54
Input is empty
In Core::Definition::Expandable[\@second... /localhome/leo/perl5/lib/perl5/LaTeXML/Engine/LaTeX.pool.ltxml; line 5810
<= Core::Gullet[@0x55ae2ee8d820] <= Core::Stomach[@0x55ae2ee86630] <= Core::Definition::Primitive[Begin] <= ...
Error:unexpected:\@personname Attempt to end mode text
at orcidlink.tex; line 7 col 0 - line 7 col 54
current frame is boxing group due to T_CS[\lx@hyper@url@] orcidlink.tex; line 7 col 0 - line 7 col 54
In Core::Stomach[@0x55ae2ee86630] /localhome/leo/src/LaTeXML/t/graphics/orcidlink.tex; from line 7 col 0 to line 7 col 54
<= Core::Definition::Constructor[\@perso... <= Core::Stomach[@0x55ae2ee86630] <= Core::Definition::Primitive[Begin] <= ...
Warning:unexpected:\end{document} Attempt to end document with open groups, environments or conditionals
at orcidlink.tex; line 12 col 0 - line 12 col 14
Group opened by { orcidlink.tex; line 7 col 0 - line 7 col 54
Group opened by \@add@frontmatter orcidlink.tex; line 7 col 0 - line 7 col 54
In Core::Definition::Constructor[\end{do... /localhome/leo/perl5/lib/perl5/LaTeXML/Engine/LaTeX.pool.ltxml; line 414
This is with the version of TikZ distributed in TeXLive 2025.
@duetosymmetry It is probably best to wait a little longer before jumping into independent testing on a PR.
As you have encountered, texlive 2025 isn't a supported latexml target yet, as we are still unwinding regressions we encountered with texlive 2022. We're nearing on a release that achieves that, but big pieces are pending in other open PRs, so I suggest holding off on fresher tests until we get everything in place.
As a general performance note: Raw TeX interpretation is a wonderful capability, but it is inevitably slow in the perl runtime. Using a prebuilt SVG can actually be better for two reasons - it is faster to build the final document and we have a guarantee of correctness that doesn't vary with texlive version.
Seconding @dginev : orcidlink is really just a single command \orcidlink{id}, right? That should be easiest (& fastest) as a native LaTeXML constructor (a ref around an svg img), I'd think.
I'd be happy to play with it, unless somebody's itching to try it out (I'd hate to spoil all the excitement)
@brucemiller in the latest version (v1.1.0) from about a year ago, I added the three formats that ORCID recommends: full, compact, and inline, through the commands \orcidlinkf{orcid}, \orcidlinkc{orcid}, and \orcidlinki{Name}{orcid} (this was a request from a PR). All three actually use the same \orcidlinkX{before}{orcid}{after} convenience function, and the icon itself is generated by \orcidlogo. The latter is what generates SVG.
@brucemiller https://github.com/brucemiller in the latest version (v1.1.0) from about a year ago,
Thanks for the links & info. I was able to quickly cobble a version that looks pretty nice; and for a useless trivial test case is actually faster than pdflatex loading pgf! I'll followup...
Regarding the inclusion of the logo in LaTeXML: I don't see anything wrong with it, but recently the OSDA package was removed from TeX Live because of similar trademark issues. I suspect that the OSDA issue was a little overblown and it could have been included, but I wasn't paying attention.
I figure (hope) that LaTeXML can include the logo but you will probably need to include a comment somewhere in COPYING or similar to report the terms of use. For instance, in the same way Wikimedia hosts a CC public domain version of the logo.
Other than that, I agree that this should be implemented in straight Perl! My PR was a good stress test of the LaTeXML internals, but embedding an SVG is so much faster... Please close this PR when you have a new one ready.
Other than that, I agree that this should be implemented in straight Perl! My PR was a good stress test of the LaTeXML internals, but embedding an SVG is so much faster... Please close this PR when you have a new one ready.
Yeah sorry to steal the graphics fun... And the stress testing is great and very welcome; don't stop! Of course, when we seem to need XeTeX internals, something seems a bit off...