[NTG-context] Re: QR Code
On Mon Dec 18, 2023 at 9:35 PM CET, Pablo Rodriguez via ntg-context wrote:
> On 12/18/23 20:34, Henning Hraban Ramm wrote:
> > [...]
> > Are you using MkIV (LuaTeX) or LMTX (LuaMetaTeX)?
>
> Many thanks for your reply, Hraban.
>
> I understood my issue with your reply (I known, your answer is intended
> to Uschi).
>
> It is also in the sent file:
>
> Creator:
>LuaMetaTeX 2.10.11 20230908 + ConTeXt LMTX 2023.09.26 18:19
> PDF Producer:
>LuaMetaTeX-2.10.11
>
> > I guess a missing EPS means you load the MkIV version of the module,
> > probably because "m-zint".
> >
> > I can’t help with Windows; since Hans developed it on Windows, it should
> > work (but don’t ask me how).
>
> I will try to explain what I understand from this (intended for Uschi).
>
> Given that there are two modules (m-zint and zint), there are two options:
>
> 1. Either you use the LMTX module (\usemodule[zint]) and you need the
> Zint library (as explained in
> https://wiki.contextgarden.net/Barcodes#Zint_module).
>
> 2. Or you use the MkIV module (\usemodule[m-zint]) and you need the Zint
> binary installed and CMD should be able to invoke it (already knowing
> its past).
>
> You may have the Zint binary installed, ConTeXt may be generating the
> required EPS files, but either Inkscape is not installed (or its path is
> unknown to the system), or ConTeXt cannot simply find where the
> converted PDF versions of the zint images are.
>
> If I have the following source in testing-barcodes.tex:
>
> \usemodule[m-zint]
> \starttext
> \startTEXpage[offset=1dk]
> \barcode[alternative=isbnx, text=9783865419026, width=4cm]
> \stopTEXpage
> \stoptext
>
> ConTeXt compiles it generating to extra files (when compared to the pure
> zint module for LMTX only):
>
> zint-isbnx-fe90eda0e93cf020312eps
> m_k_i_v_zint-isbnx-fe90eda0e93cf020312_eps_c60ccda70ef.pdf
>
> (Removed some characters in strings so file names fit in a single line.)
>
> The first file is generated by the Zint binary itself. The second one is
> the automatic conversion (through Inkscape) that ConTeXt needs to embed
> EPS (and SVG) files in the final PDF document.
>
> If m_k_i_v_zint-*.pdf files are missing, the problem might be that
> Inkscape isn’t installed (or its path is unknown to the system).
>
> If also zint-*.eps files are missing, you should find where Zint is
> generating them.
I will just add to the excellent answers above, that I very much
recommend LMTX and the LMTX way of using the zint _library_. I published
compiled versions of zint and couple of other libraries to the optional
libraries repository:
https://github.com/contextgarden/luametatex-optional-libraries
https://github.com/contextgarden/luametatex-optional-libraries/releases/tag/v20230902
I tested the steps on the wiki and libzint.dll works without problems:
i.e. install ConTeXt, create a few folders, move the dll and
mtxrun --generate.
My goto document for testing zint, that went without problems (even the
hexagons!):
\starttext
\usemodule[zint]
\barcode[alternative=isbnx, text=9783865419026, width=4cm]
\barcode[alternative=qrcode, text={https://wiki.contextgarden.net},
width=3cm]
\barcode[alternative=maxicode, text={test}, width=3cm]
\stoptext
Michal
PS: Coincidentally zint 2.13 has been released just today. Usually every
new zint release requires an update on the ConTeXt side, but older
releases still work well with ConTeXt (e.g. currently ConTeXt supports
2.10, 2.11 and 2.12). The version linked above works.
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl /
https://mailman.ntg.nl/mailman3/lists/ntg-context.ntg.nl
webpage : https://www.pragma-ade.nl / https://context.aanhet.net (mirror)
archive : https://github.com/contextgarden/context
wiki : https://wiki.contextgarden.net
___
[NTG-context] Re: named destinations in /GoToR
Hello Pablo,
On Mon Nov 13, 2023 at 5:25 PM CET, Pablo Rodriguez via ntg-context wrote:
> Dear list,
>
> imagine I have a PDF document (named "whatever.pdf") such as the one
> generated from this source:
>
> \setupinteraction[state=start,
> focus=standard]
> \starttext
> \dorecurse{5}
> {\chapter[\recurselevel]{Chapter}
> \section[sec-\recurselevel]{Section}}
> \stoptext
>
> This source only samples PDF documents not generated with ConTeXt. This
> means that no .tuc file may be available and named destinations may
> contain only digits.
>
> Then I need to access some named destinations from a document such as:
>
> \setupinteraction[state=start,
> focus=standard]
> \starttext
> \dorecurse{5}
> {\goto{Chapter \recurselevel}[whatever.pdf::\recurselevel],
> \goto{section \recurselevel}[whatever.pdf::sec-\recurselevel]\par}
> \stoptext
>
> Sorry, but after reading again lpdf-ano.mkxl I’m not sure whether I can
> get named destinations (such as "/D (4)" or "/D (sec-3)") and how I
> could get them.
>
> With the previous code, the only destination reads in the PDF source:
>
> 5 0 obj
> <<
> /D [ 0 /Fit ]
> /F (whatever.pdf)
> /S /GoToR
> >>
> endobj
It seems that the default mode for outer (external file) references is
the "auto" mode. This one seems to load the whatever.pdf file, check the
named destinations and decide based on that.
I am not exactly sure why your example fails, because it seems desirable
that the auto mode detects the named destination and refers to it
instead, or at least refers to the page number the destination is
actually at.
In any case, you can try the "name" mode, which forces the use of
destination names (i.e. "/D (...)"):
% both inner and outer references in name mode
\setupinteraction[page=name]
% inner default (auto mode) and outer name mode
\setupinteraction[page={auto,name}]
Unfortunately, the second one doesn't work due to a typo in
strc-ref.lmt:
--- a/tex/context/base/mkxl/strc-ref.lmt
+++ b/tex/context/base/mkxl/strc-ref.lmt
end
if toboolean(outer) or outer == v_page or outer == v_yes then
outermethod = v_page
-elseif inner == v_name then
+elseif outer == v_name then
outermethod = v_name
else
outermethod = v_auto
Other thing you can try Pablo, is to not actually have the destination
file (whatever.pdf) present when running context. This works, because if
ConTeXt can't find the file, the auto mode fails and you get named
destinations unless in page mode (`page=page`).
Whether something better can be done (and in a backwards compatible way)
at the ConTeXt side I am not sure, I didn't go that deep.
Michal
PS: Sorry if this message finds its way onto the list twice, I got
blocked by automoderation by initially also including the full
strc-ref.lmt file, which is too big.
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl /
https://mailman.ntg.nl/mailman3/lists/ntg-context.ntg.nl
webpage : https://www.pragma-ade.nl / https://context.aanhet.net (mirror)
archive : https://github.com/contextgarden/context
wiki : https://wiki.contextgarden.net
___
[NTG-context] Re: Building luametatex with Lua symbols exposed
On Wed Aug 30, 2023 at 6:23 PM CEST, Jairo A. del Rio wrote:
> Hi, beloved list. Since sources are in the distribution, I've tried
> compiling luametatex by setting LMT_STRIP in CMakeLists.txt to 0, yet the
> resulting binary still warns about undefined symbols, such as lua_gettop,
> when an external library is loaded in Lua. Any ideas on how to solve it?
Hi Jairo,
you need to expose _dynamic_ symbols in your luametatex binary. If you
are using Linux, just adding the following to the CMake invocation line
should work:
-DCMAKE_EXECUTABLE_ENABLE_EXPORTS=1
For example, I compiled with:
cmake -S . -B build -DCMAKE_BUILD_TYPE=Release
-DCMAKE_EXECUTABLE_ENABLE_EXPORTS=1
cmake --build build -j10
You can check the difference in dynamic symobls with:
readelf --dyn-syms build/luametatex
Note, that while this approach doesn't require any modification to
luametatex's source files, it does export _all_ symbols, which makes
binaries bigger, and symbol resolution slower. It also exports also
symbols that are not intended to be used by external modules, like
"tex_get_x_token".
Back when luametatex source code wasn't available, I created a demo
which showed how to build a "luametatex like application" (i.e.
executable with Lua statically linked in), with exported dynamic
symbols, working with CMake on both Unix and Windows. It might interest
you:
https://github.com/vlasakm/lua-demo
To support Windows in the case of luametatex, "#define LUA_BUILD_AS_DLL"
would need to be added when compiling Lua.
The problem with any module is, that you want to compile against exactly
the same Lua headers as the ones in luametatex, and with similar flags.
That is why the demo hosts everything in one CMake setup, but since
Lua's API hopefully doesn't change in the 5.4 series, you are probably
fine even with separate compilation.
IIRC stripping (LMT_STRIP) applies only to static symbols ("symbols")
and not the dynamic ones ("dynamic symbols"), and thus should be
irrelevant.
It seems that people had similar issues before:
https://www.mail-archive.com/ntg-context@ntg.nl/msg97764.html
https://www.mail-archive.com/ntg-context@ntg.nl/msg98184.html
I think it would be nice to support this "by default", but in that case,
the binary size would have to be addressed, and only the "supported"
public API of luametatex actually exposed. Support of this could also be
behind a compile time switch, but I am not sure how useful would that
be.
Michal
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / https://www.ntg.nl/mailman/listinfo/ntg-context
webpage : https://www.pragma-ade.nl / http://context.aanhet.net
archive : https://bitbucket.org/phg/context-mirror/commits/
wiki : https://contextgarden.net
___
[NTG-context] Re: zint 2.12.0 barcode generator
On Sun Aug 20, 2023 at 6:28 PM CEST, Keith McKay wrote: > Hi all, > > I've updated the zint barcode generator on my mac mini to 2.12.0 and now > no barcode is produced. I have this vague recollection that it is only > the 2.10.0 version of zint which works in ConTeXt. If I am correct, is > ConTeXt likely to be updated so that 2.12.0 works? I originally > installed zint with Homebrew. There is a very complicated thread on > stackoverflow on how to downgrade to previous versions of a formula in > homebrew, but it is far too complicated for my wee brain. Hans updated ConTeXt to account for 2.12.0 already in April, so it should work, but maybe there is some subtle error (like there was when we upgraded to 2.11). Unfortunately I am unable to take a closer look until the end of the month. In the meantime can you please try to compile the library yourself? Here are the instructions: https://github.com/contextgarden/luametatex-optional-libraries I.e. on Linux (please adjust for macOS): git clone --recursive https://github.com/contextgarden/luametatex-optional-libraries.git cd luametatex-optional-libraries cmake -S . -B build -DCMAKE_BUILD_TYPE=Release cmake --build build -j4 cp build/libzint.so /path/to/context/tex/texmf-linux-64/bin/lib/luametatex/libs/libzint.so The repository is still based on zint 2.11, I will update it to 2.12 after I confirm that it works. Michal ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / https://www.ntg.nl/mailman/listinfo/ntg-context webpage : https://www.pragma-ade.nl / http://context.aanhet.net archive : https://bitbucket.org/phg/context-mirror/commits/ wiki : https://contextgarden.net ___
Re: [NTG-context] question about multimedia renderings
uilt in, while e.g. mp4 support
relies
-- on wrapping in swf. We used to stay ahead of the pack with support of the
fancy
-- pdf features but it backfires and is not worth the trouble. And yes, for
control
-- (even simple like starting and stopping videos) one has to revert to
JavaScript,
-- the other fragile bit. And, now that adobe quits flash in 2020 we're without
any
-- video anyway. Also, it won't play on all platforms and devices so let's wait
for
-- html5 media in pdf then.
--
-- See mail by Michal Vlasák to the mailing list that discusses current support
in
-- viewers and also mentions (and submitted) a few fixes wrt embedding media.
The
-- old sound and movie features are gone.
local tonumber, next = tonumber, next
local gmatch, gsub, find, lower = string.gmatch, string.gsub, string.find,
string.lower
local filenameonly, basefilename, filesuffix, addfilesuffix = file.nameonly,
file.basename, file.suffix, file.addsuffix
local isfile, modificationtime = lfs.isfile, lfs.modification
local stripstring = string.strip
local settings_to_array = utilities.parsers.settings_to_array
local settings_to_hash = utilities.parsers.settings_to_hash
local sortedhash, sortedkeys = table.sortedhash, table.sortedkeys
local report_media = logs.reporter("backend","media")
local report_attachment= logs.reporter("backend","attachment")
local context = context
local texgetcount = tex.getcount
local getmacro = tokens.getters.macro
local hpacknode= nodes.hpack
local pdfbackend = backends.registered.pdf
local nodeinjections = pdfbackend.nodeinjections
local codeinjections = pdfbackend.codeinjections
local registrations= pdfbackend.registrations
local executers= structures.references.executers
local variables= interfaces.variables
local v_hidden = variables.hidden
local v_auto = variables.auto
local v_embed = variables.embed
local v_max= variables.max
local v_yes= variables.yes
local v_no = variables.no
local v_compress = variables.compress
local v_list = variables.list
local v_title = variables.title
local lpdf = lpdf
local pdfconstant = lpdf.constant
local pdfnull = lpdf.null
local pdfdictionary= lpdf.dictionary
local pdfarray = lpdf.array
local pdfreference = lpdf.reference
local pdfunicode = lpdf.unicode
local pdfstring= lpdf.string
local pdfboolean = lpdf.boolean
local pdfaction= lpdf.action
local pdfborder= lpdf.border
local pdftransparencyvalue = lpdf.transparencyvalue
local pdfcolorvalues = lpdf.colorvalues
local pdfflushobject = lpdf.flushobject
local pdfflushstreamobject = lpdf.flushstreamobject
local pdfflushstreamfileobject = lpdf.flushstreamfileobject
local pdfreserveobject = lpdf.reserveobject
local pdfpagereference = lpdf.pagereference
local pdfshareobjectreference = lpdf.shareobjectreference
-- symbols
local presets = { } -- xforms
local function registersymbol(name,n)
presets[name] = pdfreference(n)
end
local function registeredsymbol(name)
return presets[name]
end
local function presetsymbol(symbol)
if not presets[symbol] then
context.predefinesymbol { symbol }
end
end
local function presetsymbollist(list)
if list then
for symbol in gmatch(list,"[^, ]+") do
presetsymbol(symbol)
end
end
end
codeinjections.registersymbol = registersymbol
codeinjections.registeredsymbol = registeredsymbol
codeinjections.presetsymbol = presetsymbol
codeinjections.presetsymbollist = presetsymbollist
-- comments
-- local symbols = {
-- Addition = pdfconstant("NewParagraph"),
-- Attachment = pdfconstant("Attachment"),
-- Balloon = pdfconstant("Comment"),
-- Check= pdfconstant("Check Mark"),
-- CheckMark= pdfconstant("Check Mark"),
-- Circle = pdfconstant("Circle"),
-- Cross= pdfconstant("Cross"),
-- CrossHairs = pdfconstant("Cross Hairs"),
-- Graph= pdfconstant("Graph"),
-- InsertText = pdfconstant("Insert Text"),
-- New = pdfconstant("Insert"),
-- Paperclip= pdfconstant("Paperclip"),
-- RightArrow = pdfconstant("Right Arrow"),
-- RightPointer = pdfconstant("Right Pointer"),
-- Star = pdfconstant("Star"),
-- Tag = pdfconstant("Tag"),
-- Text = pdfconstant(&q
Re: [NTG-context] zint module on LMTX
On Sun Sep 4, 2022 at 1:25 PM CEST, Hans Hagen via ntg-context wrote: > although i don't like top do it i cloned the zint repos and tried to > compile (after migrating the proj file to vs2022) but it fails on some > png.h file missing and i see no way to disable png) Sorry, I don't have native windows compiler to test, but the options you probably want with zint's cmake are: -DZINT_USE_PNG=OFF -DZINT_USE_QT=OFF For example I use: cmake -S . -B build -DCMAKE_BUILD_TYPE=Release -DZINT_USE_PNG=OFF -DZINT_USE_QT=OFF from the root of repository. IIRC older versions may not support -S for source directory and -B for build directory so something like you had can be used: mkdir build cd build cmake -DZINT_USE_PNG=OFF -DZINT_USE_QT=OFF .. The ZINT_USE_PNG cmake option decides whether to pass -DNO_PNG to the compiler. In my repository I don't use zint's cmake at all, and compile the files manually (though also with cmake), and I set NO_PNG unconditionally: https://github.com/vlasakm/context-optional-libraries/blob/12085e89688332d2d672471ea47ef9a2c066a14f/CMakeLists.txt#L58 On Sun Sep 4, 2022 at 1:43 PM CEST, Hans Hagen via ntg-context wrote: > For some reason i get > > CMake Error: Unknown argument --toolchain > For older versions following should work: -DCMAKE_TOOLCHAIN_FILE=cross-windows.cmake instead of the newer: --toolchain cross-windows.cmake Michal ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / https://www.ntg.nl/mailman/listinfo/ntg-context webpage : https://www.pragma-ade.nl / http://context.aanhet.net archive : https://bitbucket.org/phg/context-mirror/commits/ wiki : https://contextgarden.net ___
Re: [NTG-context] zint module on LMTX
On Sun Sep 4, 2022 at 11:59 AM CEST, Ivan Pešić via ntg-context wrote:
> Дана 04.09.2022. у 12:36, ntg-context-requ...@ntg.nl пише:
>
> looks like the library is loaded ... so what is your test
>
> we don't do png, we do outlines (actually native zint graphic structures
> that we then convert with mp)
>
> Hans
>
>
>
> Hi Hans,
> here is the example that I used, basically I took it from the from the
> module:
>
> \starttext
> \usemodule[zint]
> \startTEXpage
> \barcode[alternative=PDF417,text={Hans Hagen}]%
> \blank
> \barcode[alternative=pdf417,text={Ton Otten}]%
> \blank
> \barcode[alternative=ISBN,text=9789490688011]%
> \blank
> \barcode[alternative=isbn,text=9789490688011,width=3cm]%
> \blank
> \dontleavehmode
> %\barcode[alternative=qr code,text={This is ConTeXt MKIV : #1}]
> \barcode[alternative=qr code,text={This is ConTeXt LMTX}]
> \barcode[alternative=qr code,text={\input{tufte}},width=3cm]
> \stopTEXpage
> \stoptext
>
> The resulting PDF has just empty page
>
> Best regards,
> Ivan
First, try without the \startTEXpage / \stopTEXpage, so you don't have
empty first page.
Now, as mentioned, the library loads correctly, but luametatex can't
read the binary structures passed in memory by zint. This can be due to
ABI mismatch for different versions. This was already discussed and
since then also solved by option 3 from
https://www.mail-archive.com/ntg-context@ntg.nl/msg102152.html
So already for a while ConTeXt explicitly supports zint 2.10 and 2.11,
while explicitly not supporting anything older. Newer may work, but that
remains to be seen with the 2.12 release (2.11.x should still be
compatible). In particular the development version 2.11.1.9 doesn't seem
to break anything.
Are you sure you are using the right ConTeXt LMTX and zint versions?
I just tested with fresh ConTeXt LMTX install in a Windows virtual
machine and with my build of zint (2.11.1):
https://github.com/vlasakm/context-optional-libraries/releases/download/v20220904/libzint.dll
and it works as expected.
You can also try to build the libraries yourself from the repository:
https://github.com/vlasakm/context-optional-libraries
The aspiration was that this repository would pin the "known to work
versions" of optional libraries and prepare build instructions for them.
But it is now largely untested. I can only say that zint works, as I
haven't tried others in a while. On the other hand from what I know
zint is the only fragile one, other optionals are much more less likely
to break.
Michal
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / https://www.ntg.nl/mailman/listinfo/ntg-context
webpage : https://www.pragma-ade.nl / http://context.aanhet.net
archive : https://bitbucket.org/phg/context-mirror/commits/
wiki : https://contextgarden.net
___
Re: [NTG-context] How can I make a Gentoo Linux package for ConTeXt LMTX?
On Wed Aug 24, 2022 at 11:32 PM CEST, Hans Hagen wrote:
> On 8/24/2022 10:21 PM, Michal Vlasák via ntg-context wrote:
>
> > Or rather no solution would be needed at all, since the "mtxrun" and
> > "context" wrapper commands and "texmfcnf.lua" files will be probably
> > specific for each packaging target (different directories on different
> > distros, and Unix vs Windows), and thus the matter of packagers. And
> > copying a binary and a directory with runtime files is the usual task of
> > an install step of "package descriptions", so maybe even a Makefile like
> > I had wouldn't be needed.
>
> just a note: the mtxrun[.exe] and context[.exe] commands are not really
> wrappers but symlinks to the binary luametatex[.exe] (i didn't test if
> mtxrun.lua and context.lua can be symlinks but that are to be in the
> same path in order to be seen)
Yes, sorry I should have been clearer. What is necessary for luametatex
to run a Lua script is to run it with another name (argv[0]). This can
be done with symlinks, or with `exec -a mtxrun luametatex`. And even
mtxrun.lua and context.lua can be symlinks, it works, I used it.
> one can actually use the default texmf.cnf if one sets TEXMF or one of
> its companions .. they default to be autoparent which is natural for tds
Thanks, indeed the config file sets the paths nicely, so it isn't
necessary to have another file if one sets TEXMF, very nice!
One addition I had was the use of $TEXMFDOTDIR instead of "." as the
first path in most variables, e.g.:
TEXINPUTS = "$TEXMFDOTDIR;$TEXMF/tex/{context,plain/base,generic}//",
instead of
TEXINPUTS = ".;$TEXMF/tex/{context,plain/base,generic}//",
I quite like it for adding directories with my macros / bib files etc.
that are not structured as TDS tree, but rather are "flat".
It's originally from TeX Live:
https://github.com/TeX-Live/texlive-source/commit/f1dfa7b7670fa28451c386fb08e2b32d293741ab
It lists ".//" as another possible use. Could you also add it?
I updated the repo:
https://github.com/vlasakm/context
Now also `context` is an executable (two more symlinks, so now 4
symlinks and one binary in total). There is no longer a configuration
file by me (the fallback contextcnf.lua gets used or user provides one),
the drawback being that I set some variables in the environment and the
user now can't override them from config file only from environment,
AFAIK. Also
mtxrun --variables
doesn't work now (maybe other things) though I won't investigate further
for now.
Anyway, thanks for the clarifications and suggestions!
Michal
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / https://www.ntg.nl/mailman/listinfo/ntg-context
webpage : https://www.pragma-ade.nl / http://context.aanhet.net
archive : https://bitbucket.org/phg/context-mirror/commits/
wiki : https://contextgarden.net
___
Re: [NTG-context] How can I make a Gentoo Linux package for ConTeXt LMTX?
On Tue Aug 23, 2022 at 3:11 AM CEST, Max Chernoff wrote:
> > On Sunday, August 21st, 2022 at 7:13 PM, Michal Vlasák > gmail.com> wrote:
> > >
> > > There is documentation about how it can be used. I hope its obvious how
> > > I got "texmf" (texmf-context.zip, unzip, delete some files I didn't want
> > > to take up space),
>
> One suggestion: instead of unpacking and committing "texmf-context.zip",
> I'd recommend adding
>
>https://github.com/contextgarden/context-mirror/
>
> as a git submodule. That way, it's easy to keep the files up-to-date, your
> repo will use less space, and there's a clearer separation between your
> package files and ConTeXt itself.
Yes, you are right that would be much better.
Unfortunately it seems that git submodules are not included in archives
created by `git archive` (which is also what Github uses for the
automatic release zip / tars that I have linked above). As I wanted the
published tarballs / zips self-contained ("offline only"), I would need
to use some script to generate custom archives that I would upload to
Github as release assets. This would require special care both from me
and the hypothetical packagers who would have to use the less
discoverable asset instead of the standard "git(hub) archive" way.
Anyway I think that a much better solution can be made once luametatex
source code becomes available - then there wouldn't be a reason to
resort to commiting binaries into version control and/or unnecessarily
restrict to Linux only.
Or rather no solution would be needed at all, since the "mtxrun" and
"context" wrapper commands and "texmfcnf.lua" files will be probably
specific for each packaging target (different directories on different
distros, and Unix vs Windows), and thus the matter of packagers. And
copying a binary and a directory with runtime files is the usual task of
an install step of "package descriptions", so maybe even a Makefile like
I had wouldn't be needed.
> > > A bit of a disclaimer: I don't really recommend pursuing this further.
> > > Some time ago I was also that foolish to try to package TeX for Linux
> > > distributions. Unfortunately I think that the result will never by
> > > optimal - as demonstrated by the previous discussions, the usual
> > > purposes of packages (to integrate software into the system) don't apply
> > > much to TeX / ConTeXt - there one wants something more or less self
> > > contained (so that updates are under control, no random non-essential
> > > libraries brake things, etc.).
>
> Well packaging the files into .rpm/.deb isn't really a bad idea; what's
> bad is the weird modifications that distros make, plus the fact that
> nearly every distro delays updates by quite some time. I generally agree
> that installing TeX straight from the source is better, although I can
> see why some users prefer to install from their distro repos.
One benefit of the fact that ConTeXt LMTX is not packaged anywhere came
to my mind: when someone has a problem with ConTeXt there is a very high
chance that it isn't because they are using a very old version. In
contrast to MkIV where one can imagine up to 4 year old installs (say up
to 1 year delay in TeX Live and 3 years in the distro for the "stable"
ones).
Michal
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / https://www.ntg.nl/mailman/listinfo/ntg-context
webpage : https://www.pragma-ade.nl / http://context.aanhet.net
archive : https://bitbucket.org/phg/context-mirror/commits/
wiki : https://contextgarden.net
___
Re: [NTG-context] How can I make a Gentoo Linux package for ConTeXt LMTX?
On Mon Aug 15, 2022 at 2:03 PM CEST, amano.kenji via ntg-context wrote: > TexLive has texmfcnf.lua that doesn't really work with texlive-context > installed by linux distributions. > > Arch Linux has its own patched version of texmfcnf.lua. > > It seems I'd be better off with a linux package for ConTeXt LMTX. > > How can I build and install ConTeXt LMTX on Gentoo Linux or any linux > distribution? > > I wish it was as simple as ./configure, make, and make install. Some of the problems were mentioned in previous discussions. Like: - you would need to maintain your own "snapshots" of the current ConTeXt (or make use of the public git mirror) - you currently can't build luametatex binary from source, you would have to download it prebuilt (and also keep snapshots of it) - different directory structure expected by Linux distributions (FHS, "file hierarchy standard") vs TeX (TDS, "TeX directory structure") In addition, there are still many uncertain things, like how you want to handle fonts: - install some with ConTeXt? (In that case you might distribute fonts already available in your Linux distribution) - use system ones? (Then your documents may be subject to breakages from uncoordinated updates - ConTeXt has goodie files tuned to particular versions of fonts) Also, AFAIK, packages are diligent with keeping license information and documentation, you would have to decide how that information would be kept (this is mostly the directory structure problem). With that said, taking Hans' instructions as a start: On Fri Aug 19, 2022 at 3:11 PM CEST, Hans Hagen via ntg-context wrote: > Not sure what you mean here but basically a (future) installation is: > > - unzip the main zip file > - goto the source subtree > - run build.sh (assumes compiler and cmake installed) > - move the binary file to the relevant bin location > - set symlinks from luametatex to mtsrun and context > - copy mtxrun.lua and context.lue there too > - adapt your path > - maybe add texmf-fonts and texmf-projects > - and you're done You need two things from ConTeXt: texmf directories (there are two provided by ConTeXt "texmf-context" - what you really need, "texmf" - mostly fonts) and the luametatex binary. For simplicity let's only include "texmf-context": In that case you need to extract "mtxrun" (rename to "luametatex") from http://lmtx.pragma-ade.nl/install-lmtx/context-linux-64.zip and download the "texmf-context" texmf tree from http://lmtx.pragma-ade.nl/install-lmtx/texmf-context.zip. This is how you get luametatex to execute script like mtxrun or context: - luametatex binary gets executed with name (argv[0])
Re: [NTG-context] Setting up zint on a mac with macOS Montery Version 12.3.1
On Mon May 30, 2022 at 8:19 PM CEST, Jan-Erik Hägglöf via ntg-context wrote: > With latest LMTX installed on my Monterey intel MacBook Air and Zint version > 2.11 > > optional> using library > '/Users/janneman/CTX/tex/texmf-osx-64/bin/lib/luametatex/zint/libzint.so' > zint> something went wrong: invalid result vector > zint> something went wrong: invalid result vector > zint> something went wrong: invalid result vector > … Luametatex is still built against zint 2.10, which is on the binary level incompatible with 2.11, so you should try 2.10 in the meantime. Ultimately there are three possibilities for the long run: 1) Everyone sticks with 2.10 (which may be problematic since binaries for this "old" version may gradually cease to be available). 2) Hans updates luametatex to zint 2.11, which would mean that a lot of people would need to update their zint installations now (and possibly in the future for every update). This is what was done last time with the update to 2.10. 3) luametatex gains compatibility with 2.10 *and* 2.11. Not sure what is the best way to proceed, since 3) is the messiest implementation wise, but nicest for the users. Michal Vlasák PS: Previously I also suggested option 4: The optional libraries for selected platforms would be built on the context garden and available for download (perhaps incorporated into the not yet existing module manager?). Building the some of the small libraries is easy, but for the advanced ones one would have to also build transitive dependencies and this gets out of hand quickly with e.g. curl (and in this case the returns are diminishing - curl AFAIK is so stable, that such breakage like with zint shouldn't ever happen). For what it's worth, this is my repository which allows building some of the simple libs on Linux (with the possibility to cross compile to Windows). It will probably also work on Mac. The versions of the libraries are pinned e.g. zint is locked to 2.10, so at least that should work, but I didn't follow closely updates to others in luametatex. https://github.com/vlasakm/context-optional-libraries ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://context.aanhet.net archive : https://bitbucket.org/phg/context-mirror/commits/ wiki : http://contextgarden.net ___
Re: [NTG-context] Archlinux: updated BPKGBUILD for luametatex
On Wed Dec 15, 2021 at 9:32 PM CET, Aditya Mahajan via ntg-context wrote: > > > i never came to a 'download option' because it was ot clear where to > > > download from .. are there zips? > > > > Not sure if it's for every package, but should be just > > > > "http://mirrors.ctan.org/; .. data.ctan.path .. ".zip" > > > > in scripts.ctan.details. > > This corresponds the "Download" link on the CTAN page of each package, > but unfortunately, is not always in TDS format. For example, for pgf > (which is locate at /graphics/pgf/base), we have > > https://mirrors.ctan.org/graphics/pgf/base.zip > > which lists all tex related files in base/tex sub-directory. The CTAN > page (https://www.ctan.org/pkg/pgf) also has a field "TDS Archive", > which lists: > > http://mirrors.ctan.org/install/graphics/pgf/base/pgf.tds.zip > > which is TDS compliant. The same is the case for circuitikz and > pgfplots. So, it safer to use > > "http://mirrors.ctan.org/; .. data.ctan.path .. "/" .. pkg_name .. > "tds.zip" > > But, for context packages, CTAN does nto have the tds zips (I guess > because the default zip is already TDS compliant). For example: > > https://www.ctan.org/pkg/context-filter > > has the "download" link at the bottom but not the "TDS Archive" link. > > In the end, since I am only installing 4-5 packages, it is simpler to > input the URLs but hand rather than write code to automate the logic. Oops, sorry, I completely forgot to mention that indeed what I mention corresponds to the download link on the package page, which in general "shouldn't be" in TDS format. Only packages whose authors upload their own TDS zip have these .tds.zip files you found: From https://www.ctan.org/help/upload-pkg: > The CTAN team has decided that packages on the archive shall remain in > a browsing-friendly layout, i.e. the best format is to have all the > files inside a directory. Very large packages – such as modern font > distributions – are improved by a single extra layer of directories. > > In parallel to the main directory tree, CTAN offers possibility to > provide a TDS-structured ZIP file. Such a file will only be accepted > as an addition to your upload, not as a replacement. > > This file is not necessary at all for simple packages. Thus it should > be omitted for instance for normal LaTeX packages. This file might be > required when the package is complex. Michal Vlasák ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://context.aanhet.net archive : https://bitbucket.org/phg/context-mirror/commits/ wiki : http://contextgarden.net ___
Re: [NTG-context] Archlinux: updated BPKGBUILD for luametatex
On Wed Dec 15, 2021 at 7:28 PM CET, Hans Hagen via ntg-context wrote: > On 12/15/2021 6:22 PM, Aditya Mahajan via ntg-context wrote: > > Hi all, > > > > I am changing the way modules are installed in the ArchLinux aur package > > for luametatex. > > > > https://aur.archlinux.org/packages/luametatex/ > > > > Earlier, I was just sym-linking to the modules installed by > > context-minimals-git package (which I also maintain). However, some > > packages there were out of date (in particular pgf/tikz). The new PKGBUILD > > installs the modules directly from CTAN. > > > > The following modules are installed by default: > > filter, vim, visualcounter, pgf, pgfplots, circtuitikz > > > > You can install other modules by adding them in the PKGBUILD. > > > > I am not sure if anyone else actually uses this PKGBUILD to maintain an > > up-to-date installation of LMTX. If someone does use it, and wishes to add > > more modules to the default list, I'll be happy to do that. > Just curious ... we have this > > >mtxrun --script ctan --packages --pattern=tikz > > which just gives info (at the time i made that the ctan api was bugged > as it mixed up xml and json keys, but i'm not sure if that was fixed of > became bug=feature for practical reasons) > > i never came to a 'download option' because it was ot clear where to > download from .. are there zips? Not sure if it's for every package, but should be just "http://mirrors.ctan.org/; .. data.ctan.path .. ".zip" in scripts.ctan.details. E.g. from https://ctan.org/json/2.0/pkg/lm: ctan.path = /fonts/lm => zip url = http://mirrors.ctan.org/fonts/lm.zip I think it may be better to get packages from TeX Live. They are already "built" (although this is probably not necessary for packages that ConTeXt is interested in) and split into documentation, sources and runtime files. The TeXLive database: http://mirrors.ctan.org/systems/texlive/tlnet/tlpkg/texlive.tlpdb or http://mirrors.ctan.org/systems/texlive/tlnet/tlpkg/texlive.tlpdb.xz E.g: name lm category Package revision 58637 shortdesc Latin modern fonts in outline formats relocated 1 longdesc The Latin Modern family of fonts consists of 72 text fonts and [...] docfiles size=657 RELOC/doc/fonts/lm/GUST-FONT-LICENSE.TXT RELOC/doc/fonts/lm/MANIFEST-Latin-Modern.TXT [...] runfiles size=10645 RELOC/fonts/afm/public/lm/lmb10.afm RELOC/fonts/afm/public/lm/lmbo10.afm [...] Then: http://mirrors.ctan.org/systems/texlive/tlnet/archive/lm.tar.xz http://mirrors.ctan.org/systems/texlive/tlnet/archive/lm.doc.tar.xz Some packages also have "srcfiles" and the source files tar: http://mirrors.ctan.org/systems/texlive/tlnet/archive/X.source.tar.xz PS: To be frank I didn't manage to even run the mtx-ctan script, seems like a problem with locating libs-imp-curl.lmt, although util-jsn.lua is fine and is also "require"d. [...] resolvers | libraries | locating, level '1', method 'already loaded', name 'util-jsn' resolvers | libraries | locating, level '1', method 'preload table', name 'util-jsn' resolvers | libraries | locating, level '1', method 'lua variable format', name 'util-jsn' resolvers | libraries | registered lua format path 1: . resolvers | libraries | registered lua format path 2: /home/michal/texmf/tex/context/ resolvers | libraries | registered lua format path 3: /home/michal/src/context/tex/texmf-project/tex/context/ resolvers | libraries | registered lua format path 4: /home/michal/src/context/tex/texmf-fonts/tex/context/ resolvers | libraries | registered lua format path 5: /home/michal/src/context/tex/texmf-local/tex/context/ resolvers | libraries | registered lua format path 6: /home/michal/src/context/tex/texmf-modules/tex/context/ resolvers | libraries | registered lua format path 7: /home/michal/src/context-mirror/tex/context/ resolvers | libraries | registered lua format path 8: /home/michal/src/context/tex/texmf-linux-64/tex/context/ resolvers | libraries | registered lua format path 9: /home/michal/src/context/tex/texmf/tex/context/ resolvers | libraries | registered lua format path 10: /home/michal/texmf/tex/plain/base/ resolvers | libraries | registered lua format path 11: /home/michal/src/context/tex/texmf-project/tex/plain/base/ resolvers | libraries | registered lua format path 12: /home/michal/src/context/tex/texmf-fonts/tex/plain/base/ resolvers | libraries | registered lua format path 13: /home/michal/src/context/tex/texmf-local/tex/plain/base/ resolvers | libraries | registered lua format path 14: /home/michal/src/context/tex/texmf-modules/tex/plain/base/ resolvers | libraries | registered lua format path 15: /home/michal/src/context-mirror/tex/plain/base/ resolvers | libraries |
Re: [NTG-context] Any initial thoughts on luau?
rovides the bit library, but the surface is "clean double only") - requires certain unidiomatic coding style for achieving performance - limited platform support (LuaJIT has to specifically be ported to each architecture, but the current support is pretty solid) - in the past total size of objects was limited to be 2 GiB (this is no longer true with GC64 mode) - LuaTeX specifically has had problems with LuaJIT's hash function, I don't know the details though - while the code without C API use would be JITable, the benefits may not be large, since TeX runs are not that long, although there are critical parts of code that would certainly benefit Surely I somewhere forgot an important point for or against the theoretical idea. But Hans, I would still appreciate your general opinion, even though I remember some document saying that you already disregarded this possibility. Kind regards, Michal Vlasák ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://context.aanhet.net archive : https://bitbucket.org/phg/context-mirror/commits/ wiki : http://contextgarden.net ___
Re: [NTG-context] upload
Hello,
On Thu Oct 21, 2021 at 8:04 PM CEST, Hans Hagen via ntg-context wrote:
> I cleaned up some more backend code. There were some mails about dates
> and such and although the date field in setupinteraction works ok a more
> drastic overload is doen with directives. The reason is that the fact
> that we can set the date (and traler) is only because it permits
> generating pdf files that can be compared. No date as a bad idea anyway.
>
> \setupinteraction[title=My Title]
> % \enabledirectives[backend.date=2034-06-07]
> \enabledirectives[backend.date=no]
> \enabledirectives[backend.trailerid=no]
I checked the backend code and some of the related os functions. I put
together a patch that hopefully fixes some stuff and doesn't break
anything. The changes:
1) Dates parsed by ConTeXt (function converters.totime), such as those
that are input to backend.date, now allow specifying seconds and time
zone information. If there is no timezone the datetime is presumed to be
in local time, otherwise the datetime is offset by the local / specified
time zone difference (because ConTeXt outputs these dates as local times
with local timezone). Additionally both "T" and " " are now allowed as
date/time separator characters. Thus dates output by ConTeXt can be also
fed in.
2) Fix the os.timezone function. Previously, it could be wrong around
midnight, which I discovered only by chance. The trick is lifted from
http://lua-users.org/wiki/TimeZone, which I hope is OK. The before and
after (I am at +02:00):
os.localtime() 2021-10-22 01:44:24
os.now()2021-10-21 23:44:24
os.timezone(true) -22:00
os.localtime() 2021-10-22 01:46:23
os.now()2021-10-21 23:46:23
os.timezone(true) +02:00
I also extended the interface of os.timezone to accommodate 1), but as
this is probably a very public interface, I am not sure if these changes
are OK. If more changes to the interface can be made, I propose to get
rid of the delta parameter, since it seems like a remnant from the past.
Some caching can also be introduced, but I again wasn't sure if this
even would be the final form of the function, so didn't do anything in
that sense, yet.
3) Don't use %X in time formats. It is specified to be platform
dependent and we want %H:%M:%S everywhere. Also, it would be nice if
lpdf-xmp.lmt would use the os.fulltime() function to format dates (like
back-exp.lmt does), but there are multiple dates with different formats
and purposes and it is probably too late to change now.
4) I changed the os.fulltime function, that returns date + time + local
time zone to output the _local_ time instead of UTC time. This is AFAICT
the right way to do times. The PDF spec says:
If no UT information is specified, the relationship of the specified
time to UT shall be considered to be GMT. Regardless of whether the
time zone is specified, the rest of the date shall be specified in
local time.
EXAMPLE: For example, December 23, 1998, at 7:52 PM, U.S. Pacific
Standard Time, is represented by the string D:199812231952-08'00
A test program:
\enabletrackers[backend.info]
\enabledirectives[backend.date=1234-12-30]%
1234-12-30T00:00:00+02:00
\enabledirectives[backend.date=1234-12-30 23:45] %
1234-12-30T23:45:00+02:00
\enabledirectives[backend.date=1234-12-30 23:45:16] %
1234-12-30T23:45:16+02:00
\enabledirectives[backend.date=1234-12-30T23:45:16+01:00] %
1234-12-31T00:45:16+02:00
\enabledirectives[backend.date=1234-12-30 23:45:16-02:00] %
1234-12-31T03:45:16+02:00
\enabledirectives[backend.date=1234-12-30 23:45:16+05:00] %
1234-12-31T20:45:16+02:00
\starttext
dummy text
\startluacode
print("os.timezone(true)", os.timezone(true)) -- +02:00
print("os.fulltime()", os.fulltime()) -- 2021-10-22 17:38:38+02:00
print("os.localtime()", os.localtime()) -- 2021-10-22 17:38:38
print("os.now()", os.now()) -- 2021-10-22 15:38:38
\stopluacode
\stoptext
I don't claim to know LPEG so please check my work. I also know nothing
about XMP, so I didn't check that at all, sorry.
Is the timezone stuff what you wanted Pablo?
Full patch temporarily at this URL and also below:
https://github.com/contextgarden/context-mirror/compare/beta...vlasakm:dates
Michal
--- a/tex/context/base/mkiv/core-con.lua
+++ b/tex/context/base/mkiv/core-con.lua
@@ -17,7 +17,7 @@ slower but look nicer this way.
--ldx]]--
local floor = math.floor
-local osdate, ostime = os.date, os.time
+local osdate, ostime, ostimezone = os.date, os.time, os.timezone
local concat, insert, reverse = table.concat, table.insert, table.reverse
local lower, upper, rep, match, gsub = string.lower, string.upper, string.rep,
string.match, string.gsub
local utfchar, utfbyte = utf.char, utf.byte
@@ -1972,13 +1972,18 @@ implement {
}
local n = R("09")^1 / tonumber
+local sign = S("+-") / function(s)
Re: [NTG-context] setting date in \setupinteraction
On Tue Oct 19, 2021 at 8:51 PM CEST, Pablo Rodriguez via ntg-context wrote:
> On 10/19/21 6:23 PM, Michal Vlasák via ntg-context wrote:
> > On Tue Oct 19, 2021 at 5:47 PM CEST, Pablo Rodriguez via ntg-context wrote:
> > [...]
> > So this works:
> >
> >
> > \setupinteraction[state=start,
> > date={2022-02-02T12:00:21+02:00}]
> > \starttext
> > This document is from 02.02.2020 at 12:00:21.
> > \stoptext
> >
> > This parameter sets the "ModDate" is that what you are after?
>
> Hi Michal,
>
> many thanks for your fast reply.
>
> I would like to import both metadata values (CreationDate and ModDate)
> from another file (such as https://pdf.ousia.tk/metadata.pdf).
>
> Besides from the fact that LMTX doesn’t work with this (only MkIV does
> [already reported]), isn’t no simpler way to get ISO 8601 formatting
> from doc.Info.ModDate than the following one?
>
> \starttext
> \startluacode
> function document.transfer_metadata(name)
> local main_doc = lpdf.epdf.load(name)
> context.setupinteraction{ title = main_doc.Info.Title }
> context.setupinteraction{ date = main_doc.Info.ModDate:sub(3,6) ..
> "-" .. main_doc.Info.ModDate:sub(7,8) .. "-" ..
> main_doc.Info.ModDate:sub(9,10) .. "T" ..
> main_doc.Info.ModDate:sub(11,12) .. ":" ..
> main_doc.Info.ModDate:sub(13,14) .. ":" ..
> main_doc.Info.ModDate:sub(15,22):gsub("'", ":") }
> context(main_doc.Info.Title .. "\\par")
> lpdf.epdf.unload(name)
> end
> \stopluacode
> \unexpanded\def\TransferMetadata#1%
> {\ctxlua{document.transfer_metadata("#1")}}
> \startTEXpage[offset=1em, align=center]
> \TransferMetadata{metadata.pdf}
> \stopTEXpage
> \stoptext
>
> > Seems that "CreationDate" could be set by the SOURCE_DATE_EPOCH
> > environment variable, but I am not succesfull with it right now.
>
> It would be fine to ble able to set CreationDate. Otherwise, having a
> ModDate prior to CreationDate gives a weird impression.
I don't know how official these interfaces are. But you can try adapting
the following to your use case.
\setupinteraction[state=start]
%\luacode{lpdf.settime("2020-02-02 12:00")}
%\luacode{lpdf.settime(1580641221)}
\startluacode
local Y, M, D, h, m, s, Zs, Zh, Zm =
string.match("D:20200202120021+02'00'",
"^D:(%d%d%d%d)(%d%d)(%d%d)(%d%d)(%d%d)(%d%d)([%+%-])(%d%d)%'(%d%d)%'$")
local time = os.time{year=Y,month=M,day=D,hour=h,min=m,sec=s}
lpdf.settime(time)
\stopluacode
\starttext
This document is from 02.02.2020 at 12:00:21.
\stoptext
The pattern doesn't catch all the PDF spec cases, but should match what
ConTeXt emits. The timezone info gets overwritten by current timezone
though.
Requires the below patch.
Michal
--- a/tex/context/base/mkiv/core-con.lua
+++ b/tex/context/base/mkiv/core-con.lua
@@ -1991,7 +1991,7 @@ function converters.totime(s)
end
local n = tonumber(s)
if n and n >= 0 then
-return date("*t",n)
+return osdate("*t",n)
end
end
diff --git a/tex/context/base/mkxl/lpdf-ini.lmt
b/tex/context/base/mkxl/lpdf-ini.lmt
index 7979b80..9703ac0 100644
--- a/tex/context/base/mkxl/lpdf-ini.lmt
+++ b/tex/context/base/mkxl/lpdf-ini.lmt
@@ -1123,7 +1123,7 @@ do
n = converters.totime(n)
if n then
converters.settime(n)
-timestamp = osdate("%Y-%m-%dT%X") .. ostimezone(true) --
probably not ok
+timestamp = osdate("%Y-%m-%dT%X", ostime(n)) ..
ostimezone(true) -- probably not ok
end
end
if metadata then
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://context.aanhet.net
archive : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___
Re: [NTG-context] setting date in \setupinteraction
On Tue Oct 19, 2021 at 5:47 PM CEST, Pablo Rodriguez via ntg-context wrote:
> Dear list,
>
> I have the following sample:
>
> \setupinteraction[state=start,
> date={02.02.2022}]
> \starttext
> This document is from 02.02.2020 at 12:00:21.
> \stoptext
>
> Which is the right way to get PDF dates working with \setupinteraction?
According to lpdf-mis.lmt about the "date" parameter:
-- users should enter the date in 2010-01-19T23:27:50+01:00 format
-- and if not provided that way we use the creation time instead
I can get this format also with `date --iso-8601=seconds` or the shorter
`date -Iseconds`.
So this works:
\setupinteraction[state=start,
date={2022-02-02T12:00:21+02:00}]
\starttext
This document is from 02.02.2020 at 12:00:21.
\stoptext
This parameter sets the "ModDate" is that what you are after?
Seems that "CreationDate" could be set by the SOURCE_DATE_EPOCH
environment variable, but I am not succesfull with it right now.
Michal
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://context.aanhet.net
archive : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___
Re: [NTG-context] zint barcode module on LMTX/MacOS
On Sun Sep 5, 2021 at 7:37 PM CEST, Hans Hagen wrote: > On 9/5/2021 5:51 PM, Michal Vlasák via ntg-context wrote: > > Hello Hraban, > > > "execute" should be a function defined in LuaMetaTeX, that internally > > calls zint functions. > does > > context libs-imp-zint.mkxl > > produce something? Empty page (empty content stream) and Crop/Media/TrimBox is [ 0 0 7.790488 103.5872 ]. The line: local result = zintlib_execute(specification) returns false each time. Michal ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://context.aanhet.net archive : https://bitbucket.org/phg/context-mirror/commits/ wiki : http://contextgarden.net ___
Re: [NTG-context] zint barcode module on LMTX/MacOS
On Sun Sep 5, 2021 at 6:30 PM CEST, Henning Hraban Ramm via ntg-context wrote: > > Am 05.09.2021 um 17:51 schrieb Michal Vlasák : > > "execute" should be a function defined in LuaMetaTeX, that internally > > calls zint functions. > > Hm, ok, but where are the zint API calls defined? Sorry, do you mean what zint functions luametatex calls to implement "execute"? Then I don't know. And a quick reverse engineering try didn't turn up anything either. Michal ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://context.aanhet.net archive : https://bitbucket.org/phg/context-mirror/commits/ wiki : http://contextgarden.net ___
Re: [NTG-context] zint barcode module on LMTX/MacOS
Hello Hraban, On Sun Sep 5, 2021 at 4:15 PM CEST, Henning Hraban Ramm via ntg-context wrote: > Hi again, > > the LMTX zint module uses libzint, while MkIV calls the zint binary. > The latter works for me, the first not. > > On MacOS, the library is "/opt/local/lib/libzint.dylib"*. > I changed that in the source and the file appears to be found. > Could you add that, Hans? From libraries-mkiv: It is best to keep libraries in a place where you can keep an eye on them being updated, like c:/data/tex-context/tex/texmf-win64/bin/lib/luametatex/foo/libfoo.dll You could of course use the ones provided by the system or maybe use symbolic links so that you still keep en eye on changes. On Linux I get: resolvers > libraries > library 'libzint' resolved via 'tds lib' path to '/home/michal/src/context/tex/texmf-linux-64/bin/lib/luametatex/zint/libzint.so' where the file is a copy of the system library. You probably need a similar setup (but you should prefer symlink), also with a ".so" extension as that's what ConTeXt uses on non Windows systems. > *) Previously, zint for MacOS was only available via HomeBrew; I don’t > know where that would install libzint, probably in /usr/local/lib/ like > on Linux. Yesterday a MacPorts port was added that I used; MacPorts > install everything under /opt/. In libs-ini.lua essentially three ways are tried: 1) TDS search, thats what I used above 2) PATH search (but this will try paths like "/usr/local/bin" not "/usr/local/lib"). 3) Current directory Copying the library file as I did is probably not the best idea in general, since the library can have dependencies (zint requires libpng which in turn needs zlib) and those get loaded from the system paths anyways: 28099: file=/home/michal/src/context/tex/texmf-linux-64/bin/lib/luametatex/zint/libzint.so [0]; dynamically loaded by /home/michal/src/context/tex/texmf-linux-64/bin/luametatex [0] 28099: file=libpng16.so.16 [0]; needed by /home/michal/src/context/tex/texmf-linux-64/bin/lib/luametatex/zint/libzint.so [0] 28099: file=libz.so.1 [0]; needed by /usr/lib/libpng16.so.16 [0] and one would want to ensure ABI compatibility. But then again, same issue applies to the luametatex -> optional library ABI. > But then still zintlib.execute returns nothing. I can confirm this as well. > I wonder if this works on Windows? > The API docs don’t mention an "execute" function. > https://www.zint.org.uk/manual/chapter/5 "execute" should be a function defined in LuaMetaTeX, that internally calls zint functions. Michal ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://context.aanhet.net archive : https://bitbucket.org/phg/context-mirror/commits/ wiki : http://contextgarden.net ___
Re: [NTG-context] JavaScript in multimedia PDF
On Thu Aug 12, 2021 at 12:55 AM CEST, Hans Hagen via ntg-context wrote:
> Hi
>
> > -Type = pdfconstant(MediaPermissions),
> > +Type = pdfconstant("MediaPermissions"),
> That's an interesting one ... easilly goes unnoticed ... thanks
To put credit where its due, this was Pablo's find.
Indeed very subtle, I didn't notice at all, and PDF viewers also
probably mostly ignore these "/Type"s.
Michal
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://context.aanhet.net
archive : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___
Re: [NTG-context] JavaScript in multimedia PDF
More context is in previous messages, but here is the patch for ConTeXt
to make scripting multimedia possible:
--- a/tex/context/base/mkxl/lpdf-wid.lmt
+++ b/tex/context/base/mkxl/lpdf-wid.lmt
@@ -649,6 +649,7 @@ local function insertrenderingwindow(specification)
Subtype = pdfconstant("Screen"),
P = pdfreference(pdfpagereference(page)),
A = a, -- needed in order to make the annotation clickable
(i.e. don't bark)
+T = pdfunicode(label), -- title (for JS)
Border = bs,
C = bc,
AA = actions,
@@ -693,7 +694,7 @@ local function insertrendering(specification)
-- }
-- }
local parameters = pdfdictionary {
-Type = pdfconstant(MediaPermissions),
+Type = pdfconstant("MediaPermissions"),
TF = pdfstring("TEMPALWAYS"), -- TEMPNEVER TEMPEXTRACT
TEMPACCESS TEMPALWAYS / needed for acrobat/wmp
}
local descriptor = pdfdictionary {
@@ -723,7 +724,7 @@ local function insertrendering(specification)
local rendition = pdfdictionary {
Type = pdfconstant("Rendition"),
S= pdfconstant("MR"),
-N= label,
+N= pdfunicode(label),
C= pdfreference(pdfflushobject(clip)),
}
mf[label] = pdfreference(pdfflushobject(rendition))
@@ -761,6 +762,20 @@ function codeinjections.processrendering(label)
end
end
+-- needed mapping for access from JS
+local function flushrenderings()
+if next(mf) then
+local r = pdfarray()
+for label, reference in sortedhash(mf) do
+r[#r+1] = pdfunicode(label)
+r[#r+1] = reference -- already a reference
+end
+
lpdf.addtonames("Renditions",pdfreference(pdfflushobject(pdfdictionary{ Names =
r })))
+end
+end
+
+lpdf.registerdocumentfinalizer(flushrenderings,"renderings")
+
function codeinjections.insertrenderingwindow(specification)
local label = specification.label
codeinjections.processrendering(label)
The patch is also be available here
https://github.com/vlasakm/context-mirror/commit/99f81beae0d13f1aecc20be187ada9eb88a2aa68
until it is applied (for full file download, which is available under
the three dots next to the file name).
The created Screen annotation will be given the title, that corresponds
to the second \placerenderingwindow parameter. So here:
\definerenderingwindow[soundplace]
[width=0pt, height=0pt]
\useexternalrendering[mainsound][audio/mp3][sound.mp3][embed=yes]
\placerenderingwindow[soundplace][mainsound]
both the screen annotation and rendition are available under the name
"mainsound". The name "soundplace" can be anything (even "mainsound"),
it doesn't propagate to the PDF file in any way.
And here is the patch required to make Pablo's example work:
--- a/pablo.tex
+++ b/pablo.tex
@@ -7,8 +7,10 @@
function GoToFirstSlide(label) {
this.pageNum = 0 ;
var rendition = this.media.getRendition(label) ;
+var screen = this.media.getAnnot({nPage: 0, cAnnotTitle: label}) ;
var player = app.media.openPlayer({
rendition: rendition,
+annot: screen,
});
}
The second possibility I proposed previously is not as general, and
implementing it is not worth, until it is really needed (which I presume
won't happen).
Michal Vlasák
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://context.aanhet.net
archive : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___
Re: [NTG-context] JavaScript in multimedia PDF
On Mon Aug 9, 2021 at 8:32 AM CEST, Pablo Rodriguez via ntg-context wrote:
> On 8/8/21 11:00 PM, Michal Vlasák via ntg-context wrote:
> > Is there a newer document than "JavaScript for Acrobat API Reference"
> > (May 2015)?
>
> Well, the link you provided
> (https://mailman.ntg.nl/pipermail/ntg-context/2021/103023.html) is from
> February 2021:
>
> https://opensource.adobe.com/dc-acrobat-sdk-docs/acrobatsdk/pdfs/acrobatsdk_jsapiref.pdf
>
> Here is the guide to developers (from the same date):
>
> https://opensource.adobe.com/dc-acrobat-sdk-docs/acrobatsdk/pdfs/acrobatsdk_jsdevguide.pdf
Thank you, I didn't realize that they updated the document after I
saved it. The (public) update also must have been more recently than
in February (I think the 2015 one was still up in May).
I wasn't every of the guide. It seems nice.
> I get exactly the same results: screen object, but null rendition.
>
> I have no idea what it is needed here.
Sorry, in the last mail I forgot to mention one idea I had. But now I
had time to try it, and in the end came up with three different ways to
get it working (at least the multimedia part, didn't test the rest).
It turns out, that Acrobat Reader ignores the names assigned to the
Renditions -- that's why it can't be found by name (this is not
complaint with the spec). But there is another mapping of Rendition
names and objects -- the "Renditions" name tree, that maps Unicode
encoded names of renditions to the respective objects. After generating
the name tree, the method "getRendition" works correctly. This is the
possibility number one -- generate the name tree.
Another possibility uses the fact, that the "openPlayer" method needs to
know which Rendition (what to play) and Screen annotation (where to
play) to target. While in ordinary JavaScript actions one needs to
specify them manually (because there is no context), in _Rendition_ PDF
actions (that can also execute JavaScript) there is a context -- the
action specifies the annotation and rendition at the PDF dictionary
level. So possibility number two is to use JavaScript Rendition actions.
Lastly, possibility number three. If one can't play the multimedia with
JavaScript, there still is a plain (no JavaScript) Rendition action,
that can do this -- "/OP 0" (StartRendering in ConTeXt). Also one can
chain several PDF actions one after the other. So if we first play the
Rendition through this ordinary Rendition action, then we can chain
arbitrary JavaScript after it. The order is important here, because the
second action doesn't start until first one is finished (which you may
or not desire, so feel free to swap the order).
All three possibilities work in Acrobat Reader 2021.005.20060. Depending
on the length of your audio, you may be interested in the fact, that
Acrobat Reader starts playing the audio from the start, if it didn't
finish it before. And also supports only embedded files.
Foxit Reader 11.0.1.49938 supports only the second and third way. It
also starts playing the same audio multiple times if started multiple
times (the same track plays multiple times over itself). All three file
types are supported, though I only check embedded and external files
(not URL files).
There are probably functions in the JS API to achieve better control and
consequently the same behaviour in both viewers, but I didn't look.
The first two ways are not currently possible in ConTeXt. The last one
should work, because ConTeXt should support chaining actions with
/Next, although I would have to check what is the user interface
(implementation is in lpdf.action).
I however, have a proof of concept in OpTeX, that uses the package from
my thesis (but I had to extend it for the Unicode encoded Rendition name
tree). To compile, you would need OpTeX and the updated "pdfextra.opm"
from
https://raw.githubusercontent.com/vlasakm/pdfextra/master/pdfextra.opm.
But the compiled PDF from the below example is attached.
With the proof of concept, and real world PDF document available, we
should probably get the functionality into ConTeXt. First way should
work if the name tree is added (I will look into that), but also needs a
better way to refer to the screen annotations, than what I am using
below (which maybe means more book keeping, have to check). The second
way would need a new executer and its shortcut, maybe something used
like this:
\goto{...}[JSRendition{, }]
But I presume that more book keeping will be necessary.
The third way should hopefully already work.
Also, beware that both in my example, and in ConTeXt, multimedia
insertion produces whatsits, which especially when inserted with zero
dimensions like here for audio, may cause surprising interactions when
around normal typsetting content. Putting the whatsit insertion in a
page background is a way to keep it away. "back-swf.mkiv" suggests:
\setupbac
Re: [NTG-context] JavaScript in multimedia PDF
On Sun Aug 8, 2021 at 8:22 PM CEST, Pablo Rodriguez via ntg-context wrote:
> I don’t know why I get the following message:
>
> TypeError: a.doc is undefined
>
> It seems to be caused by "app.media.openPlayer", but the code is copied
> from the documentation Adobe released early this year.
Is there a newer document than "JavaScript for Acrobat API Reference"
(May 2015)?
Anyways, I thought that the culprit is that you only specify the
rendition (what to play) and not screen (where to play):
function GoToFirstSlide(label) {
this.pageNum = 0 ;
var rendition = this.media.getRendition(label) ;
+var screen = this.media.getAnnots({ nPage: 0})[0];
var player = app.media.openPlayer({
rendition: rendition,
+annot: screen,
});
}
But as it turns out, while the screen query succesfully returns an
object, the rendition query returns null.
The PDF 1.7 standard specifies that the name (/N) of Rendition PDF
object should be Unicode, but that doesn't seem to make it work either,
as does deleting the name of the media clip (which was the same).
(But I now get "Invalid arguments" error for the "app.media.openPlayer"
call, which is kind of expected.)
Can you confirm, that "rendition" is null on your side as well?
console.println(rendition);
console.println(screen);
console.show();
Michal Vlasák
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://context.aanhet.net
archive : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___
Re: [NTG-context] ECMAscript
On Sat Aug 7, 2021 at 9:57 AM CEST, Henning Hraban Ramm via ntg-context wrote: > for running the ECMAscript part of the CG journal, I cloned the repo > from https://github.com/ccxvii/mujs/ and executed "make release". > I copied the resulting files to my TeX tree: > > ll ~/lmtx/tex/texmf-osx-64/bin/lib/luametatex/mujs/ > total 2832 > -rw-r--r-- 1 hraban staff 517K 7 Aug 09:49 libmujs.o > -rw-r--r-- 1 hraban staff 9,2K 7 Aug 09:49 main.o > -rwxr-xr-x 1 hraban staff 413K 7 Aug 09:49 mujs* > -rwxr-xr-x 1 hraban staff 408K 7 Aug 09:49 mujs-pp* > -rw-r--r-- 1 hraban staff 2,9K 7 Aug 09:49 pp.o > > But apparently I need a libmujs.so – how do I make this? Try `make shared` to make a shared library (.so file). `make release` compiles the "shell" executable. Michal Vlasák ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://context.aanhet.net archive : https://bitbucket.org/phg/context-mirror/commits/ wiki : http://contextgarden.net ___
Re: [NTG-context] multimedia PDF in ConTeXt
On Fri Jul 30, 2021 at 8:53 PM CEST, Pablo Rodriguez via ntg-context wrote:
> Hi Michal and Hans,
>
> many thanks for your patch to fix multimedia objects in PDF and your
> extremely interesting and in-depth explanation about multimedia in PDF.
> Many thanks to Hans for the release of an updated latest with also
> updated documentation.
By the way, Pablo, your issue
https://www.mail-archive.com/ntg-context@ntg.nl/msg88204.html was also
solved in the last upload. Unfortunately it will probably not help you,
because Acrobat no longer supports this.
\useexternalsoundtrack
[myaudio][audio.mp3]
\checksoundtrack{myaudio}
\goto{PLAY SOUND}[StartSound{myaudio}]
But, you can use renderings instead:
\useexternalrendering[myaudiorendering]
[audio/mp3][audio.mp3][embed=yes]
\definerenderingwindow[audiowindow]
[width=0sp, height=0sp]
\definelayer[resources]
\setupbackgrounds[page][background=resources]
\setlayer[resources]{\placerenderingwindow[audiowindow][myaudiorendering]}
\goto{PLAY SOUND}[StartRendering{myaudiorendering}]
This is basically the example from "/back-swf.mkiv". Works in Acrobat.
And one can use either of the three possible file methods (embedded,
external, URL), not just external files. The layer is so that the empty
frame doesn't interfere with normal page content. No frame is drawn when
both dimensions are 0, not sure if that is a behaviour one can take as
granted. But currenntly the dimensions can't be zero.
Hans, I would omit the check for 0 dimensions of rendering window (as
already noted in the source, it is useful for sound). See patch below.
Michal Vlasák
--- a/tex/context/base/mkxl/lpdf-wid.lmt
+++ b/tex/context/base/mkxl/lpdf-wid.lmt
@@ -655,9 +655,6 @@ local function insertrenderingwindow(specification)
}
local width = specification.width or 0
local height = specification.height or 0
-if height == 0 or width == 0 then
--- todo: sound needs no window
-end
context(nodeinjections.annotation(width,height,0,d(),r)) -- save ref
return pdfreference(r)
end
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://context.aanhet.net
archive : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___
Re: [NTG-context] multimedia PDF in ConTeXt
On Fri Jul 30, 2021 at 8:53 PM CEST, Pablo Rodriguez via ntg-context wrote:
> Hi Michal and Hans,
>
> many thanks for your patch to fix multimedia objects in PDF and your
> extremely interesting and in-depth explanation about multimedia in PDF.
> Many thanks to Hans for the release of an updated latest with also
> updated documentation.
>
> Although I don’t read Czech, just out of curiosity, is your bachelor
> thesis available on the net, Michal? Thanks to theses.cz, I found
> https://is.muni.cz/th/t8qpp/DP_Vlasak_Michal_2015.pdf (only a name
> coincidence, I guess).
Sorry, should have shared the link at the first place.
https://dspace.cvut.cz/handle/10467/95065
(PLNY_TEXT) links to the full text.
(PRILOHA) is almost all files I had for the thesis. Most notably the
testing files I used. (Some were handcoded, so no sources, but these
should be readable in text editors).
> Using your sample, I have two questions:
>
> \starttext
> \setupinteraction[state=start]
>
> \useexternalrendering[myvideo][video/mp4][video.mp4][embed=yes]
>
> \definerenderingwindow[myrenderingwindow]
> [width=\textwidth, height=\textwidth]
>
> \placerenderingwindow[myrenderingwindow][myvideo]
> \stoptext
>
> Is there no way to have the video as an embedded file in the PDF
> document? (I mean, that the file is listed when the attachment panel is
> displayed.)
Currently, only attachments are added as "embedded files" (either as
"hidden", ending up in /EmbeddedFiles, or as "annotation" ending up as
/FileAttachment annotation).
Maybe "codeinjections.embedfile" can have the option to force the
reference, so that the file also ends up in /EmbeddedFiles? Should it be
default for all \externalrenderings?
My try:
https://github.com/contextgarden/context-mirror/commit/681c36d0ecfd30c05ed588eb0f37a06dd19f3492
(the full file can be located by clicking on the three dots after the
file name, then "View file" and then "Raw", resulting in:
https://github.com/contextgarden/context-mirror/blob/681c36d0ecfd30c05ed588eb0f37a06dd19f3492/tex/context/base/mkxl/lpdf-wid.lmt,
Patch can be obtained by adding .diff to the URL:
https://github.com/contextgarden/context-mirror/commit/681c36d0ecfd30c05ed588eb0f37a06dd19f3492.diff
I will probably not keep the commit on GitHub forever, it just seems
like a nice way to send quick patches -- it is visual and allows full
file/patch download. So this time full patch also included below for
future reference.)
Michal
--- a/tex/context/base/mkxl/lpdf-wid.lmt
+++ b/tex/context/base/mkxl/lpdf-wid.lmt
@@ -259,7 +259,7 @@ local function flushembeddedfiles()
for tag, reference in sortedhash(filestreams) do
if not reference then
report_attachment("unreferenced file, tag %a",tag)
-elseif referenced[tag] == "hidden" then
+elseif referenced[tag] == "hidden" or referenced[tag] == "forced"
then
e[#e+1] = pdfstring(tag)
e[#e+1] = reference -- already a reference
f[#f+1] = reference -- collect all file description references
@@ -369,6 +369,9 @@ function codeinjections.embedfile(specification)
}
local r = pdfreference(pdfflushobject(d))
filestreams[hash] = r
+if specification.forcereference == true then
+referenced[hash] = "forced"
+end
return r
end
end
@@ -705,9 +708,10 @@ local function insertrendering(specification)
descriptor = pdfreference(pdfflushobject(descriptor))
elseif option[v_embed] then
descriptor = codeinjections.embedfile {
-file = filename,
-mimetype = mimetype, -- yes or no
-compress = false,
+file = filename,
+mimetype = mimetype, -- yes or no
+compress = false,
+forcereference = true,
}
end
local clip = pdfdictionary {
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://context.aanhet.net
archive : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___
Re: [NTG-context] Multimedia, PDF and ConTeXt
On Tue Jul 27, 2021 at 8:54 AM CEST, Hans Hagen wrote:
> On 7/27/2021 12:49 AM, Michal Vlasák via ntg-context wrote:
>
> > The viewers I tested were: Acrobat Reader DC, Foxit Reader, Sumatra PDF
> > on Windows and Evince, Okular, Xpdf, MuPDF, Firefox and Google Chrome on
> > Linux.
>
> also add the new edge on windows .. there are subtle differences in
> interfaces; although it doesn't fit into this topic, printing is also
> somethign to pay attention to; browser based pdf's can crash (mem
> consumption), the sometimes present doubleside directive can also
> confuse viewers
I thought that recent Edge versions used Chrome's PDFium, as you say
with some additions (like drawing). I would have to double check that.
From what I tried, from the tested viewers only Acrobat seemed to do
something with the double sided directive, if
/ViewerPreferences <<
/Duplex /DuplexFlipLongEdge
>>
is what we are talking about.
> when it comes to checking you need to keep in mind that some readers
> start top-down (collect objects), others bottom up (xref), some use a
> mix, some apply heuristics (irr xpdf did something with t1 fonts that
> made cut/paste an issue), some are tolerant, others more strict,
> treatment of updates objects can differ, but not always consistent ...
> so, that also makes testing annotations a problem
Yeah, I noticed that some viewers have no problem with broken xref,
others do -- that is surely the symptom of top to bottom and bottom to
top as well as the tolerance.
I only tested with simplistic and mostly hand crafted documents with a
few objects. No updates. I was concerned with creating PDF with
annotations, not with adding them afterwards. (For some annotations both
make sense, not much for others.)
Although I noticed when I tried to add annotations that Acrobat didn't
even use the object generation numbers, but just added new objects.
> > 3) Multimedia ("Renditions")
> >
> > [...]
> >
> > This mechanism allows multimedia player controls, as well as PDF
> > actions. The PDF action can be either one of the predefined ones or
> > entirely specified in JavaScript (extra API is available for this).
>
> brings us to javascript ... it would be interesting to have the 'minimal
> useful' set of support needed; mupdf has javascript but nto realaly for
> annotations (for instance the ability to control layers and widget
> states would be nice ... it's trivial to program in viewers i bet)
I also looked into JavaScript. Exactly as you say MuPDF has JavaScript,
but only for forms. Firefox and Chrome also have JavaScript support, but
again mostly for forms.
None of the three support normal (not forms) JavaScript PDF actions.
Adding support presumably wouldn't be hard -- they already support some
of the API, they just don't allow it from these actions (but they do
allow Document Level JavaScript).
As you know, the JavaScript engine used in MuPDF has very Lua like C
API, so I too think that adding JavaScript API for something already
implemented in the viewer should be easy.
> > 4) 3D art
> >
> > - First appeared in PDF 1.6 (2004).
> >
> > - Only 3D files supported. This means U3D and later PRC files. The 3D
> > objects described in the files are shown in a scene whose parameters
> > (like camera position, angle, background color, etc.) can be
> > configured.
> >
> > - The source is not a file, but a "PDF stream" (which is essentially
> > embedded file with different metadata, but allows also "external
> > files" to contain the stream data).
> >
> > - The 3D functionality is nice. It allows great amount of interactivity
> > (playing with the camera, selectively disabling 3D objects, etc.) and
> > also scriptability (switching between predefined "views" with PDF
> > actions and a _lot_ of possibilities with JavaScript scripts).
> >
> > - This is the mechanism used for u3d and prc files in the ConTeXt
> > "figure" mechanism (\externalfigure).
> >
> > - Apart from the external streams (see above) everything works in Adobe
> > Acrobat. Foxit Reader also has support, but it is limited (no
> > support for JavaScript and printing).
>
> Wasn't that driven by apps like autocad? Is U3D kind of a standard that
> will stay?
My understanding is that U3D was the first thing they designed. It is
standardised by ECMA, so freely available. Then they came up with PRC,
which should be more space efficient IIRC. It is standardized by ISO, so
it is open, but not free.
Both formats seemed to worked fine in Acrobat and Foxit and I don't see
that changing soon.
Both have some writing support
[NTG-context] Multimedia, PDF and ConTeXt
\noindent
\placerenderingwindow[myrenderingwindow][myvideo]
\goto{START}[StartRendering{myvideo}]
\goto{STOP} [StopRendering{myvideo}]
\goto{PAUSE}[PauseRendering{myvideo}]
\vfil\break\noindent
\placerenderingwindow[myrenderingwindow][myvideo2]
\vfil\break\noindent
\placerenderingwindow[myrenderingwindow][myvideo3]
\stoptext
All three file source types are demonstrated. Any "video.mp4" in the
directory you compile in will do. (Works as expected in Okular on
Linux.)
This was a dump of knowledge that I gained from writing my thesis.
Sadly its in Czech, but part of it is PDF code snippets and tables
summarizing viewer support, that I can translate and provide if there is
interest. But a large part of what I deem practical today is implemented
and documented here:
http://mirrors.ctan.org/macros/luatex/optex/pdfextra/pdfextra-doc.pdf.
The source is probably hard to read, because of the "_" and "." prefixes
in the control sequences, but those can be ignored. I posted some "real"
documents in [3] and [5].
If more documents / snippets / explanations are needed I hope I can
provide them.
Sadly, while working on this, I didn't have access to the PDF 2.0
standard. My information mostly comes from the PDF 1.7 standard and
publicly known information about PDF 2.0 - the Rich Media mechanism got
included in PDF 2.0, but I am not sure in what extent did the Flash part
get included. I also don't know if there really is anything new, but
nothing suggests it. Regardless, viewer support isn't complete for
something standardized over 20 years ago, I don't expect revolution in
the PDF viewers, considering the price of the standard(s).
[1]: https://bugs.kde.org/show_bug.cgi?id=436709
[2]: https://invent.kde.org/graphics/okular/-/merge_requests/426
[3]: https://gitlab.freedesktop.org/poppler/poppler/-/merge_requests/855
[4]:
https://tex.stackexchange.com/questions/516029/media9-is-becoming-obsolete-dec-2020-any-alternatives-for-embedding-video-audio/516102
[5]: https://gitlab.com/agrahn/media9/-/issues/9
[6]: https://wiki.contextgarden.net/Command/externalfigure
[7]: https://www.mail-archive.com/ntg-context@ntg.nl/msg88639.html
Best regards,
Michal Vlasák
--- a/tex/texmf-context/tex/context/base/mkxl/lpdf-wid.lmt
+++ b/tex/texmf-context/tex/context/base/mkxl/lpdf-wid.lmt
@@ -689,22 +689,26 @@
-- B = start,
-- }
-- }
- -- local parameters = pdfdictionary {
- -- Type = pdfconstant(MediaPermissions),
- -- TF = pdfstring("TEMPALWAYS") }, -- TEMPNEVER TEMPEXTRACT
TEMPACCESS TEMPALWAYS
- -- }
+local parameters = pdfdictionary {
+Type = pdfconstant("MediaPermissions"),
+TF = pdfstring("TEMPALWAYS"), -- TEMPNEVER TEMPEXTRACT
TEMPACCESS TEMPALWAYS
+-- TEMPALWAYS - allows temporary files (needed for Acrobat /
Windows Movie Player)
+}
local descriptor = pdfdictionary {
Type = pdfconstant("Filespec"),
F= filename,
}
if isurl then
descriptor.FS = pdfconstant("URL")
+descriptor = pdfreference(pdfflushobject(descriptor))
elseif option[v_embed] then
-descriptor.EF = codeinjections.embedfile {
+descriptor = codeinjections.embedfile {
file = filename,
mimetype = mimetype, -- yes or no
compress = false,
}
+else
+descriptor = pdfreference(pdfflushobject(descriptor))
end
local clip = pdfdictionary {
Type = pdfconstant("MediaClip"),
@@ -712,8 +716,8 @@
N= label,
CT = mimetype,
Alt = pdfarray { "", "file not found" }, -- language id + message
-D= pdfreference(pdfflushobject(descriptor)),
- -- P= pdfreference(pdfflushobject(parameters)),
+D= descriptor,
+P= pdfreference(pdfflushobject(parameters)),
}
local rendition = pdfdictionary {
Type = pdfconstant("Rendition"),
--- a/tex/texmf-context/tex/context/base/mkxl/scrn-wid.mklx
+++ b/tex/texmf-context/tex/context/base/mkxl/scrn-wid.mklx
@@ -649,6 +649,7 @@
\letrenderingwindowparameter\c!closepageaction\empty
\setrenderingwindowparameter\c!width {\d_scrn_rendering_width }%
\setrenderingwindowparameter\c!height {\d_scrn_rendering_height}%
+\setrenderingwindowparameter\c!align {\v!flushleft}% don't center
annotation whatsit
\to \everypresetrenderingwindow
\permanent\tolerant\protected\def\placerenderingwindow[#window]#spacer[#rendering]%
do all in lua
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://context.aanhet.net
archive : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___
Re: [NTG-context] Problem getting lmtx version up
On Sat Jul 17, 2021 at 7:30 AM CEST, Lutz Haseloff wrote: > both binaries work in my system. > (Galaxy A50, Userland, Kali Linux) On Sat Jul 17, 2021 at 10:47 AM CEST, jdh wrote: > Both binaries you provided ran successufully. I ran them both and they > both exited with a 0 return code, when invoked with only the --help > options. > > System ran on: > HW: Raspberry Pi 4 Model B Rev 1.4 > CPU: ARM aarch64 > RAM: 8GB > SSD: 1TB > > OS: aarch64 - Raspberry Pi 64 bit OS. Based on Debian/Linux 10 Lutz, jdh, thanks for testing, great to hear that it works! Although now it remains to apply this technique to LuaMetaTeX. Without access to source code I can't try anything, but the general ideas should apply: I used Zig for cross compiling. While Zig is a full fledged programming language in its own right, it also has the ability to compile C/C++ (with built-in Clang). The more interesting part is that it also bundles different C libraries for the different targets it supports for cross compilation. This is a great match for Lua(Meta)TeX, because standard C library is the only "external" dependency. Depending on the chosen target (CPU+OS+ABI triple), the binary can then be fully statically linked or dynamically linked against the target's system C library. Zig exposes the "C compiler" functionality with two interfaces: the Zig build system and the "zig cc" command. In theory "zig cc" should be a drop-in replacement for "clang" or "gcc" [1] and therefore should be usable with existing build systems used by LuaTeX/LuaMetaTeX. In practice it is not that easy, because some "compiler feature detections" of these build systems often try to run compiled results (and fail). But in the best case (like with Lua) cross compilation may be as easy as: # "bsd" is almost like "linux", but doesn't link "readline" make CC="zig cc -target aarch64-linux-musl" bsd The result is a fully statically linked executable, that can be used on all Linux distributions. But because it is statically linked, dynamic loading of external Lua libraries written in C is not possible. The following will result in a binary that is dynamically linked against (the target system) glibc and should be able to load even Lua libraries written in C: make CC="zig cc -target aarch64-linux-gnu.2.28" bsd (Note that Zig support all relevant glibc versions, that means that compiling for older Linux distributions can be done from any OS, not just ancient Debian or CentOS. Here "2.28" is old enough to support jdh's Raspberry Pi OS -- and anything newer.) Applying this to LuaMetaTeX may or may not be hard. Frankly I don't know much about CMake. But I have experience converting LuaTeX (or rather its subset) to another build systems: 1) https://github.com/vlasakm/mmtex/blob/ltex/build.zig This was used to produce the two binaries I sent previously. Usage (no setup required): wget 'https://github.com/vlasakm/mmtex/archive/refs/tags/cross-test2.zip' unzip cross-test2.zip cd mmtex-cross-test2/ wget 'https://ziglang.org/download/0.8.0/zig-linux-x86_64-0.8.0.tar.xz' tar xf zig-linux-x86_64-0.8.0.tar.xz zig-linux-x86_64-0.8.0/zig build -Dtarget=aarch64-linux-musl qemu-aarch64 zig-out/bin/mmtex --help Something similar should work on Windows/Mac and for other targets (see `zig targets`). 2) https://github.com/vlasakm/mmtex/blob/master/mmtex/files/meson.build This one compiles full LuaTeX, although it doesn't support cross compilation and links to system zlib, libpng and zzliplib. The Zig cross compilation is sadly limited (https://ziglang.org/download/0.8.0/release-notes.html#Tier-1-Support), but not because more exotic systems will never be supported, it's just that nobody did the required work, yet. The support for Linux (various architectures), macOS (aarch64+x86_64) + Windows (x86_64) should be very good. I don't think there is other cross compiler that is able to target the M1 Macs. The Zig build you download from their website [2] is kind of huge, but note that it includes LLVM+Clang+Zig in one single dependency free binary + (efficiently packed) C libraries for many targets. I.e. this is all you need for all your C/C++/Zig. Provided that you (as of now) don't need anything other than Linux/Mac/Windows. Hans, Mojca, is this something worth pursuing for LuaMetaTeX before "native" compilation is available? I am interested in trying. Michal Vlasák [1]: https://andrewkelley.me/post/zig-cc-powerful-drop-in-replacement-gcc-clang.html [2]: https://ziglang.org/download/ ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://context.aanhet.net archive : https://bitbucket.org/phg/context-mirror/commits/ wiki : http://contextgarden.net ___
Re: [NTG-context] Problem getting lmtx version up
On Fri Jul 16, 2021 at 12:46 AM CEST, jdh wrote: > # My system has GLIBC 2.28, but I don't know how to upgrade it for RPis Can you jdh or anyone with a similar setup try to run the following two binaries? Run with '--help' only, other than that not much works. https://github.com/vlasakm/mmtex/releases/download/cross-test/ltex-aarch64-linux-gnu.2.28 https://github.com/vlasakm/mmtex/releases/download/cross-test/ltex-aarch64-linux-musl If I didn't mistake the architecture, these should work. At least I can confirm that the second (fully statically linked) one works on my x86_64 linux with: chmod +x ./ltex-aarch64-linux-musl qemu-aarch64 ./ltex-aarch64-linux-musl --help The above are cross compiled (debug) builds of very stripped down version of LuaTeX, that I have been experimenting with. They won't solve the immediate problem, but the cross compiling procedure could be used to generate luametatex binaries for this target until a better option is available. Of course, depending on whether it even works. :) Michal Vlasák ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://context.aanhet.net archive : https://bitbucket.org/phg/context-mirror/commits/ wiki : http://contextgarden.net ___
[NTG-context] nuts.setfield is nil in generic code
Hello,
in the generic font loader code `nuts.setfield` is `nil`.
This is because in `luatex-basics-nod.lua` there is a wrong assignment
for `nuts.setfield` on line 121 (there is no `setfield` at that scope,
it should be `direct.setfield`). This is the required patch:
```diff
--- a/luatex-basics-nod.lua
+++ b/luatex-basics-nod.lua
@@ -118,7 +118,7 @@ nuts.setcomponents = direct.setcomponents
nuts.setdirection = direct.setdirection
nuts.setdisc = direct.setdisc
nuts.setreplace= direct.setreplace
-nuts.setfield = setfield
+nuts.setfield = direct.setfield
nuts.setkern = direct.setkern
nuts.setlink = direct.setlink
nuts.setlist = direct.setlist
```
This surfaced because `nuts.setreplace` in the generic code is defined
in terms of `nuts.setfield`. Previously `nuts.setreplace` wasn't used
anywhere (I think), but since 20th May 2021 it is used when injecting
kerns into discretionaries (font-otj.lua):
See also https://www.mail-archive.com/ntg-context@ntg.nl/msg98463.html.
Minimal not working example is:
```
\font\f=file:{./BaskervilleF-BoldItalic.otf}:mode=node;script=latn;kern=yes;
at10pt
\f B\-C
\bye
```
Fails with:
"warning (node filter): error: ./luatex-fonts-merged.lua:5166: attempt to call
a nil value (upvalue 'setfield')".
Interestingly I can't reproduce the issue with Latin Modern, although it
seems to have a similar kern:
```
\font\f=file:lmroman10-regular.otf:mode=node;script=latn;kern=yes; at10pt
\f V\-a
\bye
```
Originally reported at https://github.com/latex3/luaotfload/issues/194.
Regards,
Michal Vlasák
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://context.aanhet.net
archive : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___
