[dev-context] Re: C best practices
On 1/19/2024 10:21 AM, Taco Hoekwater wrote:
On 19 Jan 2024, at 09:47, Shiv Shankar Dayal
wrote:
Dear Hans, Taco, Mojca and Wolfgang,
I see #define macros and gotos in LuaMetaTex code which is not good coding
practice and not recommended. These are my first observations. I have started
learning plain TeX so that I can understand the code better and send more
suggestions to the list.
Dijkstra’s “GOTO is harmful" article was not nearly as absolute as modern
programmers’ mindset.
Using more “modern" branching using "if" would not make the code faster, and it
would not automatically make it easier to understand either. A thing that is often overlooked
these days is that goto statements create a documentation label as well as doing actual
program counter update work. The “else” branch of an if-else statement in C does not have that
feature, and IMO it makes reading nested if statements more painful than code with a few
well-placed gotos.
Another issue is that when gotos are used to jump out of a switch statement,
that code can usually only be refactored by introducing new helper functions.
That will make the code base more cumbersome as well as larger (and therefore
slower).
Amen.
In cases where that is feasible, switching to branchless code would indeed help
with speed. But not with readability, at all.
Maybe but indeed worse readability. Actually I found that compilers do a
pretty good job on inlining so there is little to gain. Even link time
optimization doesn't bring more than a few percent.
In a similar fashiom we dont'use libs that have assembler optimizing bit
dependent on architecture. No gain in practice.
On the many #define’s I agree it would be nice if as many as possible of the
constants would be changed to const variables, as that would help with
debugging quite a bit. But in the end, all of it is Hans’ call.
Most of these defines are already enums and those left over are kind of
harmless (and stand out nicely in the code editor which is also a reason
for doing some thing in some way.) But occasionally i change some more.
When luametatex is kind of stable, I'll make the decission to change
some of these left overs but that also impacts compatibility (no big
deal for context for which is it meant anyway).
btw, as long as gaining a few milliseconds is offset by bad user macros,
styling, etc we can better educate usage instead of staring at code.
Hans
-
Hans Hagen | PRAGMA ADE
Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl
-
___
dev-context mailing list -- dev-context@ntg.nl
To unsubscribe send an email to dev-context-le...@ntg.nl
[dev-context] Re: Inline items indent paragraph
On 8/23/2023 10:13 PM, Wolfgang Schuster wrote:
Hi,
when inline items are used and the itemize environment has a settings
for the margin the value the whole paragraph is indented by the set
value for itemize.
\starttext
\samplefile{lorem}
\samplefile{lorem}\startitemize[a,intext][margin=2em]\item one \item two
\stopitemize \samplefile{lorem}
\samplefile{lorem}
\stoptext
The culprit in this case is the \doadaptleftskip command which keeps the
margin value even after the group has ended.
\starttext
\samplefile{lorem}
\samplefile{lorem}\bgroup\doadaptleftskip{1cm}\egroup\samplefile{lorem}
\samplefile{lorem}
\stoptext
We need a check in this case to ensure the margin settings (margin,
leftmargin and rightmargin) are ignored for inline items.
like this?
\ifconditional\c_strc_itemgroups_inline
% ignore
\orelse\ifnum\c_strc_itemgroups_nesting=\plusone % NIEUW
\doadaptleftskip {\itemgroupparameter\c!margin}%
\doadaptleftskip {\itemgroupparameter\c!leftmargin}%
\doadaptrightskip{\itemgroupparameter\c!rightmargin}%
\fi
-
Hans Hagen | PRAGMA ADE
Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl
-
___
dev-context mailing list -- dev-context@ntg.nl
To unsubscribe send an email to dev-context-le...@ntg.nl
[dev-context] Re: strc-itm.mklx
On 8/16/2023 7:23 PM, Wolfgang Schuster wrote:
Hi,
The \ifzerodim check (one line 1599 in strc-itm.mklx) doesn't work here
because it happens after the box is flushed and the width is always 0pt.
\def\strc_itemgroups_handle_groups_text_item
{\hbox
{\ifconditional\c_strc_itemgroups_sub
\dostarttagged\t!ignore\empty
+\enspace
\dostoptagged
\fi
\box\b_strc_itemgroups
\ifzerodim\wd\b_strc_itemgroups\else
\hskip\interwordspace % not configureable (yet), could be
\c!textdistance
\fi}%
\nobreak}
ha, just in time as i was going to upload
\def\strc_itemgroups_handle_groups_text_item
{\hbox
{\ifconditional\c_strc_itemgroups_sub
\dostarttagged\t!ignore\empty
+\enspace
\dostoptagged
\fi
\scratchwidth\wd\b_strc_itemgroups
\box\b_strc_itemgroups
\ifzerodim\scratchwidth\else
\hskip\interwordspace % not configureable (yet), could be
\c!textdistance
\fi}%
\nobreak}
-
Hans Hagen | PRAGMA ADE
Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl
-
___
dev-context mailing list -- dev-context@ntg.nl
To unsubscribe send an email to dev-context-le...@ntg.nl
Re: [dev-context] luametatex compiled with g++
On 12/12/2022 2:11 PM, Schultheis Erik wrote:
I'm not sure if this is the right list, if not please redirect me.
this list or the general context list
So, I tried compiling luametatex using g++, and noticed some things that
prevent it from also being considered valid C++ code.
ok, but keep in mind that we try to avoid c++ specifics
Two general problems are:
1) Initialization order. C++ wants initializers to be specified in the
order in which they will actually initialize the object, i.e. in the
order of the members.
Do you have a list of locations?
2) Reserved names. Some variables are named `class` or `template`, which
of course, breaks C++.
i'll replace these (but you need to check it as i don't compile with g++
But more interesting are the specific pieces of code that get rejected,
because C++ is a bit more strict than C in some cases.
interesting; we compile with clang, gcc and msvc and each has its own
(sometimes conflicting) messages
3) We get one complaint about comparing a pointer to an integer using <,
which I believe is an actual bug in the code.
ok, fixed
4) A second complaint is about dropping const in `tex_to_cstring`. I
don't think this causes an actual error in the program, though.
hm, changes but let's see what othjer compilers say
5) Some of the `goto`s cause problems, because the jump skips over the
initialization of variables in the target scope. Again, these variables
are not used, so I don't think there is an actual error. The easy fix
here is to just move the code from the `goto` target into its own
function, which is probably better for readability anyway.
adapted (slightly different)
6) The last problem is that things break with g++ if the marco
`infinity` is defined.
adapted but best check if i didn't make mistakes there
I've attached patches for 3), 4), and 5), as I think that these benefit
code quality in general. I can also send ones for 1) and 2), if there is
interest. 6) seems to be a more general incompatibility, I'm not sure if
there is a "fix" that doesn't require #if s.
you can check (1) and (2) next upload; we really try to avoid compiler
specific #if's
Hans
-
Hans Hagen | PRAGMA ADE
Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl
-
___
dev-context mailing list
dev-context@ntg.nl
https://mailman.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] fix for footnote hyperlink
On 10/14/2022 10:49 PM, Pablo Rodriguez wrote:
Hi Hans,
the patch fixes the regression for internal hyperlinks (footnotes and
similar) with current latest (2022.10.14 10:16).
This sample shows the issue:
\setupinteraction[state=start,
focus=standard]
\starttext
\completecontent
\section{section}
a\footnote{\contextversion}
\stopsection
\stoptext
Without the fix, destinations are referred to an unexisting 7 0 object
(instead of the page at 1 0 R).
I think this fixes the regression in current latest.
ok, thanks,
Hans
-
Hans Hagen | PRAGMA ADE
Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl
-
___
dev-context mailing list
dev-context@ntg.nl
https://mailman.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] tabl-tbl.mkxl
On 5/29/2022 9:29 PM, Wolfgang Schuster wrote:
Hi,
the \tabl_tabulate_NR_common needs \tolerant, otherwise \NR fails when
it appear at the end of an included file.
tabl-tbl.mkxl, line 1971 (LMTX only):
-\permanent\protected\def\tabl_tabulate_NR_common#1#2#.#3% #. gobbles
pars and spaces
+\permanent\tolerant\protected\def\tabl_tabulate_NR_common#1#2#.#3% #.
gobbles pars and spaces
{\global\advance\c_tabl_tabulate_noflines\plusone
...
\noalign{\the\t_tabl_tabulate_every_after_row#2}#3}
ah, fixed ...
Hans
-
Hans Hagen | PRAGMA ADE
Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl
-
___
dev-context mailing list
dev-context@ntg.nl
https://mailman.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] \showlayout (more wiki stuff)
On 11/30/2021 11:39 AM, Taco Hoekwater wrote: Hi, Here is a question about \showlayout … is that not supposed to print different variable values on each page? I tried this: \setuppagenumbering [alternative=doublesided] \definelayout[1][rightmargin=5mm,width=fit] \definelayout[even][rightmargin=80mm,width=fit] \definelayout[odd][rightmargin=50mm,width=fit] \setuplayout \starttext \showlayout[3] \stoptext and it updates the frame correctly on each page, but always prints the initial layout variables … I have 3 pages where only the frames differ. Also, there is a fourth, empty page generated, but that I do not care much about. no, the variables are only swapped on demand (in the otr and/or when we need them (e.g. when stuff goes into the margin, but then we also need to sync with the position) - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl - ___ dev-context mailing list dev-context@ntg.nl https://mailman.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] \showmakeup (wiki)
On 11/30/2021 2:55 PM, Taco Hoekwater wrote: Hi, See the bug report in: https://wiki.contextgarden.net/Command/showmakeup Does that need fixing in the interface file, or should the bug report be converted into a simple note and a pointer to check the most recent options in the actual source file? afaiks it's this now: simple box ones gone, a few more kern etc addes Hans - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl - ___ dev-context mailing list dev-context@ntg.nl https://mailman.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] \placenamedfloat ?
On 11/24/2021 1:59 PM, Taco Hoekwater wrote: I just converted the wiki page: https://wiki.contextgarden.net/Command/placenamedfloat But trying to run the example there … it doesn’t seem to work? Neither mkiv nor lmtx. sorry ... crappy lpeg ... fixed in next upload Hans - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl - ___ dev-context mailing list dev-context@ntg.nl https://mailman.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] startfigure / placestartfigure confusion
On 11/19/2021 2:35 PM, Taco Hoekwater wrote: Hi all, I was trying to document the \marking()() command (which is in itself a bit of an odd thing, but not the point of this message). It is supposedly to be used inside of \startfigure … \stopfigure (lmtx) or with the old name: \placestartfigure … \placestopfigure (mkii/mkiv) but as I was trying to produce an example, I discovered that \startfigure … \stopfigure does not seem to work at all ? no output appears. Is this command supposed to still work, even? % MWE (assuming I understand the supposed syntax correctly): \starttext \startfigure[mycow][cow.pdf][width=4cm] ... \stopfigure some text \stoptext that's an oldy ... pre-metapost, pre-positioning, pre-layers ... (maybe make it into a compatibility (auto loaded) module if not really used any more) (1) parsing issue i.e. not adapted to recent 'upgrade' (2) due to grouping the mechanism thinks ther ei sno image (so it also shows a dummy) fixed (hackerish) Hans - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl - ___ dev-context mailing list dev-context@ntg.nl https://mailman.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] \somewhere is broken in lmtx
On 11/20/2021 12:29 PM, Wolfgang Schuster wrote:
Taco Hoekwater schrieb am 19.11.2021 um 16:35:
Hi,
It just seems to typeset all its arguments, or something. Works fine
in mkiv mode.
MWE: https://wiki.contextgarden.net/Command/somewhere
(I set the wiki example up to use mkiv instead so it looks ok there)
strc-ref.mklx:
The \numexpr isn't necessary but \relax has to be added after
\referencepagedetail.
\def\strc_references_handle_page_state_yes
{\markreferencepage
- \ifcase\referencepagedetail
+ \ifcase\numexpr\referencepagedetail\relax
\expandafter\sixthofsixarguments \or
\expandafter\thirdofsixarguments \or
\expandafter\firstofsixarguments \or
\expandafter\fifthofsixarguments \or
\expandafter\secondofsixarguments\or
\expandafter\fourthofsixarguments\else
\expandafter\sixthofsixarguments \fi}
ok, also mkiv
Hans
-
Hans Hagen | PRAGMA ADE
Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl
-
___
dev-context mailing list
dev-context@ntg.nl
https://mailman.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] lmtx \fillinline bug
On 11/16/2021 3:59 PM, Taco Hoekwater wrote:
Hi,
Something goes wrong rather oddly in lmtx with \fillinline. In vmode, it does
not actually
show the fill-in line, but then it does remember it because it will appear in
the *next*
paragraph.
mkiv is fine, for comparison.
Best wishes.
Taco
% MWE:
\setuppapersize[A6,landscape]
\starttext
OK: \fillinline[width=2cm]{\it OK (hmode)} \par
\fillinline[width=2cm]{\it NOT OK (vmode)} \par
NOK, spillover!\par
\stoptext
we can add a \dontleavehmode
\permanent\tolerant\protected\def\fillinline[#1]%
{\dontleavehmode
\registerparwrapper
{fillinline}%
{\pack_fillinline_before{#1}}%
{\pack_fillinline_after {#1}%
\unregisterparwrapper{fillinline}}}
-
Hans Hagen | PRAGMA ADE
Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl
-
___
dev-context mailing list
dev-context@ntg.nl
https://mailman.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] startpagefigure (mkxl) bug
On 11/15/2021 12:36 PM, Taco Hoekwater wrote:
Hi,
\defineexternalfigure[\v!page:\v!figure][\c!offset=\v!overlay] % we force a
parent
\permanent\tolerant\protected\def\startpagefigure[#1]#*[#2]%
{\bgroup
\setupexternalfigure[\v!page:\v!figure][\c!offset=\v!overlay,#2]%
\startTEXpage[\c!offset=\namedexternalfigureparameter{\v!page:\v!figure}\c!offset,\c!align=\v!normal]%
\externalfigure[#1]\ignorespaces} % so we can put some text below the
graphic
I think that last line should be
\externalfigure[#1[\v!page:\v!figure]]\ignorespaces} % so we can put some
text below the graphic
you didn't test it ... missing ] in the patch
Hans
-
Hans Hagen | PRAGMA ADE
Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl
-
___
dev-context mailing list
dev-context@ntg.nl
https://mailman.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] Three issues: empty lines | -error.log file | simpleslides
On 10/31/2021 10:23 PM, Tomas Hala wrote:
Hi all,
during last several months I came accross three non-critical problems
worth reporting here:
1.
Empty lines at the beginning of the main file generates an error:
-ERR
This is LuaTeX, Version 1.13.0 (TeX Live 2021)
system commands enabled.
**
-
and compilation crashes. Detected at TL 2021, at two or three month old
garden installation is does not appear (maybe it has been fixed yet).
--MWE
\starttext
xxx
\stoptext
-
weird error ... smells liek an engine issue
2.
When an error during compilation of "xxx.tex" appears, the file
"xxx-error.log" is generated. But sometimes happens that file "-error.log"
is created. It makes troubles for Linux command line processing --
if user writes some mask later, "-error.log" string is interpreted by default
as list of options of a particular command.
It would be very useful if a test preventing an "empty" filename will be added.
-LOG (file -error.log)
return {
["filename"]="",
["lastcontext"]="\n<*> c\n ont-yes.mkiv --c:currentrun=1
--c:fulljobname=./pokus-1.tex --c:input=./pokus-1.tex --c:kindofrun=3 -- --c:maxnofruns=1 --c:once -- --
--c:texmfbinpath=/usr/local/texlive/2021/bin/x86_64-linux",
["lastluaerror"]="?",
["lasttexerror"]="! Interruption",
["linenumber"]=0,
["offset"]=10,
}
i'll try to catch that
3.
When simpleslides module is used, interactive element BottomSquares does not
change if the file is compiled by ConTeXt from TL2021 whereas with ConTeXt
from TL2019 it works.
-MWE
\usemodule[simpleslides][style=BottomSquares,font=Schoolbook,size=20dd,]
\starttext
\setupTitle[title=Title]
\placeTitle
\SlideTitle{A+B} blabla
\SlideTitle{CCC} blabla
\SlideTitle{D+E} blabla
\stoptext
--------
Examples attached.
dunno
Hans
-
Hans Hagen | PRAGMA ADE
Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl
-
___
dev-context mailing list
dev-context@ntg.nl
https://mailman.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] mtxrun makes x11 stuck
On 9/12/2021 1:15 AM, Sylvain Hubert wrote: Dear ConTeXt Devs, Here's a problem that I reported last year (https://mailman.ntg.nl/pipermail/ntg-context/2020/099862.html <https://mailman.ntg.nl/pipermail/ntg-context/2020/099862.html>) with a wrong description. I thought that it had something to do with Firefox or browsers, but it turns out to be a much deeper and weirder problem messing up with the X window system. Environment: Manjaro Linux 21.1.2, Xfce 4.16 Steps to reproduce: 1. `context --version` # it can hardly be any more innocent 2.1. keep striking random keys in the terminal or mounsepad or whatever 2.2. or open a running-cat.gif in the background Expected behavior: the characters should appear as you type, or the cat should keep running Actual behavior: ~3s after `context --version` finishes, the terminal freezes and the character stops appearing for ~1s, or similarly, the cat stops running for ~1s In short, ~3s upon termination of context, the X window stuck for ~1s. More information: 1. The problem only appears 2 days after the fresh installation of latest context-lmtx, which was also the case last year. 2. `context --version` isn't doing anything, so it shouldn't be a resource problem, and I've got no such problem keeping 40+ pages open in chrome anyway. 3. Below is a more precise timing of the problem. The first output is the result of `context --version` along with the start and stop timestamps. The second output is a python one-liner printing timestamps each time it reads an . Notice how python reads an per ~0.05s until 00:33:21.597326, when it is blocked for ~0.7s. I'm not sure if it's reproducible everywhere, and I'm willing to debug it myself, but I would need the source code of the context executable. i can't be of much help here but keep i nind that after an update a first run can trigger a format remake or scan for fonts so when that takes time hitting some 'run again' key can result in many simulatious runs that can add up an dmaybe stall the system Hans - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl - ___ dev-context mailing list dev-context@ntg.nl https://mailman.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] inner item group ignores options
On 9/9/2021 1:31 AM, Sylvain Hubert wrote:
Dear ConTeXt Devs,
I'm not sure if this is an expected behavior or a known issue, but
anyway, I've found that the inner \startitemize ignores margin= and
before= and probably some other options as well:
\showframe
\starttext
\startitemize[margin=2em]
\item has margin
\stopitemize
\startitemize[before=randomstuff]
\item has text before
\stopitemize
\startitemize[margin=2em]
\item .
\startitemize[margin=2em]
\item no margin
\stopitemize
\startitemize[before=randomstuff]
\item no text before
\stopitemize
\stopitemize
\stoptext
\starttext
\defineitemgroup[marginalized]
\setupitemgroup[marginalized][2][leftmargindistance=2em]
\setupitemgroup[marginalized][3][leftmargindistance=4em]
\startmarginalized
\item one: \input tufte
\startmarginalized
\item two: \input tufte
\startmarginalized
\item three: \input tufte
\stopmarginalized
\stopmarginalized
\stopmarginalized
\stoptext
Besides, do we have an official issue tracker?
There is one I lack the discipline to keep track of issue trackers so
just posting to the list is faster.
http://tracker.luatex.org -> project context
Hans
-
Hans Hagen | PRAGMA ADE
Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl
-
___
dev-context mailing list
dev-context@ntg.nl
https://mailman.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] Fwd: [NTG-context] Indexing redux
}
\index{dog breeds+Coton de Tulear}
\index{dog breeds+Dachshund}
\index{dog breeds+Weimaraner}
\page
More stuff
\index{Adams+John Quincy}
\index{misquotation}
\index{pseudepigraphy}
\index{Traven, B.}
\index{Beagle}
\index{Coton de Tulear}
\index{breeding programs}
\page
\definedescription[Index][headstyle=bold,alternative=top,inbetween=]
\startIndex{a}
Adams\par
\quad \reference[AdamsDouglas]{Adams, Douglas}Douglas\quad 1\par
\quad John\quad 1\par
\quad John Quincy\quad 2\par
\stopIndex
\startIndex{b}
Beagle\quad 1, 2\par
\reference[breedingprograms]{breeding programs}breeding
programs\quad 2
\stopIndex
\startIndex{c}
Coton de Tulear\quad 2.\par
\quad {\em See also under} \in[dogbreeds]
\stopIndex
\startIndex{d}
\reference[DentArthur]{Dent, Arthur}Dent, Arthur {\em see}
\in[AdamsDouglas]\par
\reference[dogbreeds]{dog breeds}dog breeds\par
\quad \reference[dbBeagle]{dog breeds, Beagle}Beagle\quad 1\par
\quad \reference[dbCoton]{dog breeds, Coton}Coton de
Tulear\quad 1\par
\quad \reference[dbDachshund]{dog breeds,
Dachshund}Dachshund\quad 1\par
\quad \reference[dbWeimaraner]{dog breeds,
Weimaraner}Weimaraner\quad 1\par
\quad Wiener dog\quad {\em see} \in[dbDachshund]\par
\quad{\em See also} \in[breedingprograms] {\em and specific
breeds}
\stopIndex
\startIndex{m}
Marut, Ret\quad {\em see} \in[TravenB]\par
Matilda effect\quad {\em see} \in[obliteration]\par
\reference[misquotation]{misquotation}misquotation\quad 2
\stopIndex
\startIndex{o}
\reference[obliteration]{obliteration}obliteration\quad 1\par
\quad{\em See also} \in[misquotation] {\em and}
\in[pseudepigraphy]
\stopIndex
\startIndex{p}
Prefect, Ford\quad {\em see Adams, Douglas}\par
\reference[pseudepigraphy]{pseudepigraphy}pseudepigraphy\quad 2\par
\quad {\em See also} \in[obliteration]
\stopIndex
\startIndex{t}
\reference[TravenB]{Traven, B.}Traven, B.\quad 2
\stopIndex
\startIndex{w}
Weimaraner\quad {\em see under} \in[dogbreeds]
\stopIndex
\page
\placeindex
\stoptext
--
Rik
___
If your question is of interest to others as well, please add an entry
to the Wiki!
maillist : ntg-cont...@ntg.nl <mailto:ntg-cont...@ntg.nl> /
http://www.ntg.nl/mailman/listinfo/ntg-context
<http://www.ntg.nl/mailman/listinfo/ntg-context>
webpage : http://www.pragma-ade.nl <http://www.pragma-ade.nl> /
http://context.aanhet.net <http://context.aanhet.net>
archive : https://bitbucket.org/phg/context-mirror/commits/
<https://bitbucket.org/phg/context-mirror/commits/>
wiki : http://contextgarden.net <http://contextgarden.net>
___
—
Taco Hoekwater E: t...@bittext.nl <mailto:t...@bittext.nl>
genderfluid (all pronouns)
___
dev-context mailing list
dev-context@ntg.nl
https://mailman.ntg.nl/mailman/listinfo/dev-context
--
-
Hans Hagen | PRAGMA ADE
Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl
-
___
dev-context mailing list
dev-context@ntg.nl
https://mailman.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] multi-page text background bug
On 5/10/2021 3:54 PM, Gou Lingfeng wrote:
Example:
--
\definetextbackground[undeftext][location=text,alternative=1,dash=3,background=,frame=off,voffset=-.5ex]
\starttext
Hello \starttextbackground[undeftext]
world!
\page
bbb.
\page
ccc.
\stoptextbackground
\stoptext
--
Proposed patch:
--
--- tex/texmf-context/tex/context/base/mkxl/anch-pgr.lmt.bak 2021-05-07
12:19:30.951643997 -0500
+++ tex/texmf-context/tex/context/base/mkxl/anch-pgr.lmt 2021-05-07
12:19:44.716693548 -0500
@@ -123,6 +123,9 @@
local ht = specification.ht <http://specification.ht>
local dp = specification.dp
-- this is not yet r2l ready
+-- myfix
+realpage=texgetcount("realpageno")
+-- end
local w = d.shapes[realpage]
local x, y = getpos()
if trace_ranges then
--
The module-local variable `realpage` is never changed, which is
apparently a bug.
actually it's something that got lost when the approach was change a bit
.. i'll send you another patch to test
Hans
-
Hans Hagen | PRAGMA ADE
Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl
-
___
dev-context mailing list
dev-context@ntg.nl
https://mailman.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] lpdf-ini.lmt: lpdf.tosixteen(), wrong conversion to UTF-16BE
Hi, +v = v - 0x1 ah, i hadn't noted that line (btw, in the file there is a remark where i add the 0x1 that it is inconsistent so i should have looked into it then, sigh) My other suggestion, which does the subtraction only for one surrogate is below. btw, performance wise the separate step is the same as doing it in the one liner (lua does all via the stack so in general using intermediate steps assiging to (here v) is often quite ok) Hans - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl - ___ dev-context mailing list dev-context@ntg.nl https://mailman.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] lpdf-ini.lmt: lpdf.tosixteen(), wrong conversion to UTF-16BE
On 2/9/2021 6:57 PM, Michal Vlasák wrote:
Hello,
conversion to UTF-16BE PDF strings used for example in bookmarks / PDF
outlines is not right.
Take the following example:
```
\starttext
\setupinteraction[state=start]
\placebookmarks[section][number=no]
\section[bookmark=필]
\stoptext
```
Produces: for 필 (U+1D544), instead of the correct
.
The relevant function is `lpdf.tosixteen()` (from lpdf-ini.lmt), and its
`cache`. (Although the same function is also in lpdf-aux.lmt, and in
MkIV equivalents).
My proposal (also enclosed as a file attachment):
```
--- a/lpdf-ini.lmt
+++ b/lpdf-ini.lmt
@@ -178,7 +178,8 @@
if v < 0x1 then
v = format("%04x",v)
else
-v = format("%04x%04x",rshift(v,10),v%1024+0xDC00)
+v = v - 0x1
+v = format("%04x%04x",rshift(v,10)+0xD800,v%1024+0xDC00)
end
t[k] = v
return v
```
(Note the similiarity to existing function `big()` in l-unicode.lua.)
I found this by chance, but I am not really a ConTeXt user, so I hope
didn't miss anything.
Thanks for noticing (btw, the aux file is used on some scripts, not in
context itself).
Hans
-
Hans Hagen | PRAGMA ADE
Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl
-
___
dev-context mailing list
dev-context@ntg.nl
https://mailman.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] mtx-install.lua for linuxmusl-64
On 12/23/2020 3:10 PM, Martin Hasoň wrote: Hi, the installer for linuxmusl-64 creates invalid directory for binary files. There may be a bug in the file mtx-install.lua: -- ["linux-64"] = "linux-64", ["linux64"] = "linux-64", -- - ["linuxmusl-64"] = "linuxmusl", + ["linuxmusl-64"] = "linuxmusl-64", ["linuxmusl"] = "linuxmusl", -- ["linux-armhf"] = "linux-armhf", we only have 64 bit so never had that distinction Hans - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl - ___ dev-context mailing list dev-context@ntg.nl https://mailman.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] prop-ini.mkxl: \stopproperty
On 11/21/2020 3:07 PM, Wolfgang Schuster wrote:
Hi,
\properties_stop calls itself
\protected\def\properties_stop
{\properties_stop
\popmacro\properties_stop}
I'll remove these modules ... we have better mechanisms and those were
kept for soem compatibility (that didn't work so no one used that code
anyway).
Hans
-
Hans Hagen | PRAGMA ADE
Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl
-
___
dev-context mailing list
dev-context@ntg.nl
https://mailman.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] strc-lst.mklx: \completecontent
On 11/20/2020 3:42 PM, Wolfgang Schuster wrote:
Hi,
combined lists with title are broken because they use the wrong function.
\permanent\tolerant\protected\def\definecombinedlist[#tag]#spacer[#list]#spacer[#settings]%
{\definelist[#tag][\c!criterium=\v!local,\c!reference=,\c!alternative=,\c!list={#list},#settings]%
inherits from root
\frozen\instance\setvalue{\e!setup#tag\e!endsetup}{\setupcombinedlist[#tag]}%
\frozen\instance\setvalue{\e!place#tag}{\placecombinedlist[#tag]}%
- \frozen\instance\setvalue{\e!complete#tag}{\strc_lists_complete[#tag]}}
+
\frozen\instance\setvalue{\e!complete#tag}{\strc_lists_combined_complete[#tag]}}
% \completecombinedlist ?
+\permanent\tolerant\def\strc_lists_combined_complete[#tag]#spacer[#settings]%
+
{\normalexpanded{\startnamedsection[\v!title][\c!title={\headtext{#tag}},\c!reference=#tag]}%
+ \placecombinedlist[#tag][#settings]%
+ \stopnamedsection}
or two times [#tag]:
\frozen\instance\setvalue{\e!complete#tag}{\strc_lists_complete[#tag][#tag]}}
-
Hans Hagen | PRAGMA ADE
Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl
-
___
dev-context mailing list
dev-context@ntg.nl
https://mailman.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] buff-ver.mkxl: language -1
On 11/16/2020 8:19 PM, Wolfgang Schuster wrote: Hi, I think these can be changed to use \nohyphens instead of the language hack. will do Hans - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl - ___ dev-context mailing list dev-context@ntg.nl https://mailman.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] anch-tab.mkxl: \XC
On 11/16/2020 7:15 PM, Wolfgang Schuster wrote:
Hans Hagen schrieb am 16.11.2020 um 19:05:
On 11/16/2020 6:53 PM, Wolfgang Schuster wrote:
Hi,
there are two problems in the following definitions (line 90--99).
1. Extra "s" on \ifparameter
2. \anch_table_check_state doesn't work anymore because it tries to
change the value of \dosingleempty which was used to create the
optional argument.
\permanent\tolerant\protected\def\tbXC
[#1]{\anch_table_check_state\ifparameters#1\or\anch_tables_indeed_XC
[#1]\else\expandafter\NC\fi}
\permanent\tolerant\protected\def\tbGSC[#1]{\anch_table_check_state\ifparameters#1\or\anch_tables_indeed_GSC[#1]\else\expandafter\NC\fi}
\permanent\tolerant\protected\def\tbGFC[#1]{\anch_table_check_state\ifparameters#1\or\anch_tables_indeed_GFC[#1]\else\expandafter\NC\fi}
\permanent\tolerant\protected\def\tbGTC[#1]{\anch_table_check_state\ifparameters#1\or\anch_tables_indeed_GTC[#1]\else\expandafter\NC\fi}
\def\anch_table_check_state
{\iftrialtypesetting
\global\settrue\tablehaspositions
\firstargumentfalse
\fi}
How about this:
\permanent\protected\def\tbXC
{\anch_table_checked\anch_tables_indeed_XC }
\permanent\protected\def\tbGSC{\anch_table_checked\anch_tables_indeed_GSC}
\permanent\protected\def\tbGFC{\anch_table_checked\anch_tables_indeed_GFC}
\permanent\protected\def\tbGTC{\anch_table_checked\anch_tables_indeed_GTC}
\tolerant\def\anch_table_checked#1[#2]%
{\iftrialtypesetting
\global\settrue\tablehaspositions
\expandafter\NC
\orelse\ifparameter#2\or
\expandafter#1%
\else
\expandafter\NC
\fi}
The optional argument is now gone and never passed further down, more
something like this (not sure about \tripleexpandafter)
\tolerant\def\anch_table_checked#1[#2]%
{\iftrialtypesetting
\global\settrue\tablehaspositions
\tripleexpandafter\NC\expandafter\gobbleoneoptional
\orelse\ifparameter#2\or
\expandafter#1%
\else
\tripleexpandafter\NC\expandafter\gobbleoneoptional
\fi[#1]}
We're nearly there ... pass [#2] istead of [#1] ...
\permanent\protected\def\tbXC {\anch_table_checked\anch_tables_indeed_XC }
\permanent\protected\def\tbGSC{\anch_table_checked\anch_tables_indeed_GSC}
\permanent\protected\def\tbGFC{\anch_table_checked\anch_tables_indeed_GFC}
\permanent\protected\def\tbGTC{\anch_table_checked\anch_tables_indeed_GTC}
\tolerant\def\anch_table_checked#1[#2]%
{\iftrialtypesetting
\global\settrue\tablehaspositions
\expandafter\anch_tables_indeed_NC
\orelse\ifparameter#2\or
\expandafter#1%
\else
\expandafter\anch_tables_indeed_NC
\fi[#2]}
\def\anch_tables_indeed_NC[#1]%
{\NC}
-
Hans Hagen | PRAGMA ADE
Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl
-
___
dev-context mailing list
dev-context@ntg.nl
https://mailman.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] anch-tab.mkxl: \XC
On 11/16/2020 6:53 PM, Wolfgang Schuster wrote:
Hi,
there are two problems in the following definitions (line 90--99).
1. Extra "s" on \ifparameter
2. \anch_table_check_state doesn't work anymore because it tries to
change the value of \dosingleempty which was used to create the optional
argument.
\permanent\tolerant\protected\def\tbXC
[#1]{\anch_table_check_state\ifparameters#1\or\anch_tables_indeed_XC
[#1]\else\expandafter\NC\fi}
\permanent\tolerant\protected\def\tbGSC[#1]{\anch_table_check_state\ifparameters#1\or\anch_tables_indeed_GSC[#1]\else\expandafter\NC\fi}
\permanent\tolerant\protected\def\tbGFC[#1]{\anch_table_check_state\ifparameters#1\or\anch_tables_indeed_GFC[#1]\else\expandafter\NC\fi}
\permanent\tolerant\protected\def\tbGTC[#1]{\anch_table_check_state\ifparameters#1\or\anch_tables_indeed_GTC[#1]\else\expandafter\NC\fi}
\def\anch_table_check_state
{\iftrialtypesetting
\global\settrue\tablehaspositions
\firstargumentfalse
\fi}
How about this:
\permanent\protected\def\tbXC {\anch_table_checked\anch_tables_indeed_XC }
\permanent\protected\def\tbGSC{\anch_table_checked\anch_tables_indeed_GSC}
\permanent\protected\def\tbGFC{\anch_table_checked\anch_tables_indeed_GFC}
\permanent\protected\def\tbGTC{\anch_table_checked\anch_tables_indeed_GTC}
\tolerant\def\anch_table_checked#1[#2]%
{\iftrialtypesetting
\global\settrue\tablehaspositions
\expandafter\NC
\orelse\ifparameter#2\or
\expandafter#1%
\else
\expandafter\NC
\fi}
-
Hans Hagen | PRAGMA ADE
Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl
-
___
dev-context mailing list
dev-context@ntg.nl
https://mailman.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] type-ini.mklx: \definetypescriptsynonym
On 11/9/2020 10:48 PM, Wolfgang Schuster wrote:
Hi Hans,
the \definetypescriptsynonym command still use \ifsecondargument in the
definition.
\permanent\tolerant\protected\def\definetypescriptsynonym[#name]#spacer[#synonym]%
{\ifsecondargument\setevalue{\??typescriptsynonyms#name}{#synonym}\fi}
ok, will fix ... but i'm not at a place where i can upload now
Hans
-
Hans Hagen | PRAGMA ADE
Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl
-
___
dev-context mailing list
dev-context@ntg.nl
https://mailman.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] [NTG-context] update and meeting
On 9/21/2020 4:31 PM, Wolfgang Schuster wrote:
Taco Hoekwater schrieb am 21.09.2020 um 14:44:
Hi Hans,
On 15 Sep 2020, at 18:44, Hans Hagen wrote:
(2) Another change is in the \startdocument mechanism. This (already
old and rusted) wrapper runs on top of variables but we think no one
knows (or uses) that. So, it now is a real wrapper with inheritance
and such. It is dedicated to Tomas Hala who had to struggle with the
old one but still gave a presentation using it. Here's an example:
\definedocument[thesis]
\setupdocument[a=b,e=f]
\setupdocument[thesis][a=x,c=d]
\startsetups[document:start]
START
\stopsetups
\startsetups[thesis:stop]
STOP
\stopsetups
\startthesis
(\currentdocument/a): \documentvariable{a}\par
(\currentdocument/c): \documentvariable{c}\par
(\currentdocument/e): \documentvariable{e}\par
\stopthesis
The auto-inheritance of the setups does not work yet, because the
\definedocument[thesis] does not
set up local version of the before= and after= keys of \startthesis.
\definedocument (re)defines the value of the actual setup
“thesis:start” correctly to inherit the
parent’s \directsetuo, but because the actual before and after keys
are inherited from the (document)
parent as well, the effect on \startthesis still remains equivalent to
this:
\setupdocument
[thesis]
[before=\directsetup{document:start},
after=\directsetup{document:stop}]
So we need something like this:
\appendtoks
\setexpandeddocumentparameter\c!before{\noexpand\directsetup{\currentdocument:\v!start}}%
\setexpandeddocumentparameter\c!after
{\noexpand\directsetup{\currentdocument:\v!stop }}%
\to \everydefinedocument
the reason i didn't make setups inheritable was mostly that I can't
oversee the intensions (i played a bit with it; like defining setups as
part of define so that we can have inherited setups) ... for instance
what when we have a third level (say document -> thesis -> mythesis ..
and we want to use the thesis setups)
i don't care what solution si chose as long as it doesn't break anything
at my end
Hans
-
Hans Hagen | PRAGMA ADE
Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl
-
___
dev-context mailing list
dev-context@ntg.nl
https://mailman.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] [NTG-context] update and meeting // towards 'in'
On 9/18/2020 5:56 PM, Tomas Hala wrote: So I vote for keeping it forever, eg. till Americans will completely convert to SI. btw 1: a stronger argument is that we're stuck for ever with dots per inch btw 2: if you look in page-lay you will find plenty of paper sizes that use "in" dimensions .. of course no one might use these, but still ... Hans - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl - ___ dev-context mailing list dev-context@ntg.nl https://mailman.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] [NTG-context] update and meeting // towards 'in'
On 9/18/2020 5:56 PM, Tomas Hala wrote: Hi Hans, # We also considered that in order to enforce the use of si units the # 'in' should go away but that has been postponed (it is anyway last # in the checked keywords so has no overhead). I do not remember details of the discussion about 'in' but I would like to say that 'in' is quite important unit, especially for Americans. We have to take into consideration that paper and other things are sold in inches in the USA and it is not very comfortable to recalculate it to the metric system. We can let it depend on the outcome of the elections and foreign politics ... we can use the unit as bargain option (and Alan uses thise french units anyway). So I vote for keeping it forever, eg. till Americans will completely convert to SI. It was a joke (seems you didn't pay attention when arthur and I discussed it the break ... we even mentioned 'meters' as possible units and dropping cm and mm). Dropping nd and nc is because they were never accepted as standard. An inch is official tex and we're tex aren't we? But in luametatex the inch is at the bottom of the scanned unit list .. you can guess the order that we like most; scanning for in takes 25% more time than for mm but only Idris will notice that (and when he used "truein" it will be twice as slow). Hans - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl - ___ dev-context mailing list dev-context@ntg.nl https://mailman.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] Running lists
On 9/17/2020 8:15 PM, Tomas Hala wrote: Hi all, playing with itemize environment (reverberations of our discussion with Wolfgang at the meeting) I came across the wrong settings of running lists: \starttext %\startitemize[a] \startitemize[a,text] \item xxx \item yyy \stopitemize \stoptext gives items in the running list with both parentheses and moreover a dot. For English (which is a default language) items letters (and figures as well) should be only in parentheses and without a dot. Wolfgang confirmed that there is no option to disable the stopper for running items only and proposed to add additional values to the placestopper key, e.g. \setupitemize [each] [placestopper=yes|no|inline|display] sure, as long as you wikify it ... and use > \startitem xxx \stopitem > \startitem yyy \stopitem - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl - ___ dev-context mailing list dev-context@ntg.nl https://mailman.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] Line endings with \starttypescript
On 6/16/2020 10:36 PM, Aditya Mahajan wrote:
Hi,
This question is motivated by a question of TeX.SE
(https://tex.stackexchange.com/questions/549725/context-strange-issue-with-typescript).
Basically, the OP defined
\starttypescriptcollection[fira]
...
\stoptypescriptcollection
\setuphead[section][style={\switchtobodyfont[fira,sans]}]
\starttext
\section{section 1}
\section{section 2}
\section{section 3}
\stoptext
and found that the first section was indented. As Wolfgang explained in
a comment, this happens because of the newlines at the end of each
\definesynonym in \starttypescriptcollection. Wolfgang also explained
how to avoid this error.
I am wondering if it makes sense to change the definition of
\starttypescriptcollection or \starttypescript so that newlines are
automatically ignored (similar to \startsetups).
could be but not watertight ... i'll send you some test
anyway, locally initializing a font is a bad idea, and there's a warning
on the console about it ... one can say
\usebodyfont[fira,sans]
at the top and get it predefined
Hans
-
Hans Hagen | PRAGMA ADE
Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl
-
___
dev-context mailing list
dev-context@ntg.nl
https://mailman.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] Light colors in colo-imp-rgb.mkiv
On 6/8/2020 7:36 AM, Aditya Mahajan wrote: Hi, The 'light' colors defined in colo-imp-rgb.mkiv are not light! \definecolor [lightred] [r=1, g=0, b=0] \definecolor [lightgreen] [r=0, g=1, b=0] \definecolor [lightblue] [r=0, g=0, b=1] \definecolor [lightcyan] [r=0, g=1, b=1] \definecolor [lightmagenta] [r=1, g=0, b=1] \definecolor [lightyellow] [r=1, g=1, b=0] hm, a compatibility thing Is this intentional? How about replacing them with somewhat reasonable defaults? \definecolor [lightred] [r=1, g=0.5, b=0.5] \definecolor [lightgreen] [r=0.5, g=1, b=0.5] \definecolor [lightblue] [r=0.75, g=1, b=1] \definecolor [lightcyan] [r=0.5, g=1, b=1] \definecolor [lightmagenta] [r=1, g=0.5, b=1] \definecolor [lightyellow] [r=1, g=1, b=0.5] See attached output. These are not the ideal choices in terms of shades, but I have chosen values which are least subjective and still give reasonable shades. your blue is kind of weird .. this is the metapostisch way: \definecolor [lightred] [.5(red,white)] \definecolor [lightgreen][.5(green,white)] \definecolor [lightblue] [.5(blue,white)] \definecolor [lightcyan] [.5(cyan,white)] \definecolor [lightmagenta] [.5(magenta,white)] \definecolor [lightyellow] [.5(yellow,white)] which i bet you prefer Hans - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl - ___ dev-context mailing list dev-context@ntg.nl https://mailman.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] Libertinus Mono (type-imp) -- improvement
On 5/25/2020 3:56 PM, Tomas Hala wrote: Hi, % \setupbodyfont[libertinus] \starttext a--b \startMP a--b \stopMP \stoptext % I found out that this code produces dash instead of double hyphen also when typing the code which seems not to be correct. Solution: (type-imp-libertinus.mkiv from TL2020, line 71) OLD: \definefontsynonym [\s!Mono] [LibertinusMono-Regular][\s!features=\s!default] NEW: \definefontsynonym [\s!Mono] [LibertinusMono-Regular][\s!features=\s!none] If there is no other reason to keep the default features here, I would like to propose the change above. sure, mono is always 'none' so it's a bug that we will fix Hans - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl - ___ dev-context mailing list dev-context@ntg.nl https://mailman.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] \tochar problem with symbols
On 3/9/2020 9:38 PM, Wolfgang Schuster wrote:
As can be seen in the example below "dollar" has catcode 3 and "bar" has
catcode "13".
begin example
\starttext
x\tochar{n:bar}|x
\tochar{n:dollar}x$
\stoptext
end example
ok, i'll send you somethign to test
Hans
-
Hans Hagen | PRAGMA ADE
Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl
-
___
dev-context mailing list
dev-context@ntg.nl
https://mailman.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] Different Versions of Manuals
On 3/3/2020 11:56 AM, Sebastian Miele wrote: Hans Hagen writes: On 3/1/2020 3:49 PM, Sebastian Miele wrote: The ConTeXt Excursion referenced from the garden and contained in the LMTX distribution say that they are from 2017-Oct-05. The version linked from http://www.pragma-ade.com/overview.htm says it is from 1999-May-27. The ConTeXt reference manual linked from http://www.pragma-ade.com/overview.htm is from 2001-Nov-12. The version referenced in the garden is from 2013-Sep-27. As of now, I did not find a version of the document in the distribution. Neither in ConTeXt LMTX, nor in ConTeXt Standalone. The garden copies are kind of independent. Not updated often. The website is largely the same as what is in the distribution but not entirely. (Btw, most of the website is generated automatically along with generating the current distribution zip.) The website is a bit more archival in that sense. The old ref manual (most of which still applies) has some chapters turned into what are now separate manuals. Ok, I just use the docs from the distribution and the contextref.pdf from 2013-Sep-27 linked at the garden (as neither it nor its source seem to be in the distribution). Indeed. As I am very picky about formatting of document sources and had no time (or reason) to check the ref manual it's not in the distribution. luametatex.pdf in LMTX is from Feb-18. In Standalone it is from Jan-30. Sure, sometimes we update LMTX independent from the mkiv distribution. I generate the luametatex manual (1) as a quick test and (2) to check if I messed up performance. Anyway, as the sources are distributed too one can always generate the latest greatest. Generating the manuals on my site may produce the latest (except for the lacking ConTeXt reference manual). But it cannot produce the greatest on my site, because, as of now, I am lacking Lucida and Cambria, and my financial means are extremely limited (contrary to my free time :-)). At least the LuaMetaTeX manual has a graphical example with boxes drawn around Lucida and Cambria characters in order to illustrate spacing. The font metrics used for that almost certainly come from the fonts. You can probably remap them to some other font. If you have a windows system or install some powerpoint vierwer you have cambria. I just stay with the generated PDFs. Ok. Hans - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl - ___ dev-context mailing list dev-context@ntg.nl https://mailman.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] Different Versions of Manuals
On 3/1/2020 3:49 PM, Sebastian Miele wrote: The ConTeXt Excursion referenced from the garden and contained in the LMTX distribution say that they are from 2017-Oct-05. The version linked from http://www.pragma-ade.com/overview.htm says it is from 1999-May-27. The ConTeXt reference manual linked from http://www.pragma-ade.com/overview.htm is from 2001-Nov-12. The version referenced in the garden is from 2013-Sep-27. As of now, I did not find a version of the document in the distribution. Neither in ConTeXt LMTX, nor in ConTeXt Standalone. The garden copies are kind of independent. Not updated often. The website is largely the same as what is in the distribution but not entirely. (Btw, most of the website is generated automatically along with generating the current distribution zip.) The website is a bit more archival in that sense. The old ref manual (most of which still applies) has some chapters turned into what are now separate manuals. In the following days I will start to use the most recent version of the two documents known to me. In the LMTX distribution: musings.pdf is from 2020-Jan-17, whereas musings.tex and musings-names.tex are from 2020-Feb-18. Yes, I don't generate the main docs every time I fix a typo or add a line (esp when it's not that fundamental). luametatex.pdf in LMTX is from Feb-18. In Standalone it is from Jan-30. Sure, sometimes we update LMTX independent from the mkiv distribution. I generate the luametatex manual (1) as a quick test and (2) to check if I messed up performance. Anyway, as the sources are distributed too one can always generate the latest greatest. Hans - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl - ___ dev-context mailing list dev-context@ntg.nl https://mailman.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] Typos in the LuaMetaTeX Manual
On 2/18/2020 3:04 AM, Sebastian Miele wrote: Some of these are up to two weeks old and may already have been fixed otherwise. thanks, applied - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl - ___ dev-context mailing list dev-context@ntg.nl https://mailman.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] Bug: Inline Math Surrounding Spacing
On 2/5/2020 6:47 PM, Sebastian Miele wrote: In the table on \mathsurroundmode in the LuaMetaTeX manual every example row has the same spacing, although there should be noticable differences. After trying to find the root of problem, I came to the conclusion that currently ConTeXt LMTX obeys neither \mathsurround nor \mathsurroundskip at all. It actually does work but the example code interferes with the regular context setting up of spacing so I need to trick around that (trivial) Thanks for noticing. Hans - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl - ___ dev-context mailing list dev-context@ntg.nl https://mailman.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] Minor Problems in the LuaMetaTeX Manual
On 2/4/2020 2:44 AM, Sebastian Miele wrote: The Lua(Meta)TeX manual mentiones that \leftghost and \rightghost come from Aleph. I searched the web quite a bit about Omega and Aleph on that issue, and tried other things, but found nothing of relevance. There is a manual for Omega, but, after conversion from ps to pdf, and opening the pdf with Evince, the search function did not find the phrase 'ghost' in it, either. i'm going to remove it ... we have plenty of ways to prevent ligatures and influence kerning and context nowhere uses it anyway Hans - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl - ___ dev-context mailing list dev-context@ntg.nl https://mailman.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] Minor Problems in the LuaMetaTeX Manual
Hi, The Lua(Meta)TeX manuals talk about ghost nodes. I did not find any information on what that is. Up to now, for all other stuff encountered in the LuaMetaTeX manual that I did not know and wanted to have a rough idea of what it is about, I found the relevant information either in the LuaMetaTeX manual itself, in TeX by Topic, or in the ε-TeX manual. I.e. I found it using the LuaMetaTeX manual itself, or the manuals that were referenced at the beginning of chapter 1 of the LuaMetaTeX manual as important additional material. The Lua(Meta)TeX manual mentiones that \leftghost and \rightghost come from Aleph. I searched the web quite a bit about Omega and Aleph on that issue, and tried other things, but found nothing of relevance. There is a manual for Omega, but, after conversion from ps to pdf, and opening the pdf with Evince, the search function did not find the phrase 'ghost' in it, either. Omega was to a large extend about supporting scripts and fonts for them and when doing so you sometimes need to indicate the boundry of words or glyph runs (regular tex also has a boundary char in the fonts). first hit on "omega leftghost" http://torus.math.uiuc.edu/jms/tex2mathml/omega-1.23.4/src/web_omega/omfont.ch (thinking of it, i'm not sure if we should keep it because I'm not aware of fonts that have kerns wrt left and right ghist glyphs; we do have a boundary node system instead) Hans - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl - ___ dev-context mailing list dev-context@ntg.nl https://mailman.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] sortedkeys and compare in LMTX l-table.lua
On 1/26/2020 1:17 AM, Sebastian Miele wrote:
On table.sortedkeys the page
https://www.contextgarden.net/Table_manipulation says: "Returns a sorted
array of all the keys in table t. The comparer used for sorting will
treat everything as a string iff the compared values are of mixed type."
According to l-table.lua, sortedkeys first checks whether the keys in
the given table are (1) all strings, (2) all numbers, or (3): neither
(1) or (2). In cases (1) and (2) table.sort is used with the default
comparer (Lua's '<'). In case (3) table.sort is used with a custom
compare function named 'compare' and defined in l-table.lua.
According to the sentence from the garden cited above, 'compare' should
return (something equivalent) to tostring(a) < tostring(b). However, it
does something more complex that, e.g., makes 10 < "2" < 3 < 10 ('<'
meaning infix 'compare' here). I.e. there are strict circles in the
strict order.
https://www.contextgarden.net/Table_manipulation goes on explaining
that, "In general this means that you will be fine as long as you avoid
stuffing indices along with number hashes together in t, lest the order
will end up confused depending on what type an element is compared with
in what order (cf. example [2])."
This reflects the way 'compare' actually is at the moment. But it
contradicts the previous sentence "The comparer used for sorting will
treat everything as a string iff the compared values are of mixed type."
If everything is treated as a string when neither (1) nor (2), then
everything is well-defined and there is no confusion.
Why is 'compare' not just (something equivalent to) tostring(a) <
tostring(b), violating the sentence cited above? Are there any
meaningful uses of the way 'compare' is now?
I suspect that the intent was to create an order that is lexicographic
and numeric at the same time. As far as I see it, it just is not
possible the way it was tried: Lexicographically, 11<2. Numerically,
2<11.
I see three ways out: (1) Disallow mixed types of keys in tables given
to sortedkeys. (2) Always use lexicographic order in the case of mixed
key types. (3) Combine the orders by an order-theoretic sum. One
possiblity: Every value that is neither a number nor a string is smaller
than every number. Every number is smaller than every string. Otherwise
elements are compared as they are now. Another possiblity: Define an
order over all types, define an order for every type. Then sort by type
first, and in type second.
(1) may not possible without breaking a lot. (2) has sort of a
discontinuity: E.g., add one numeric key to a table with only strings,
and the order changes globally. (3) contains well defined, very
predictable solutions without discontinuities.
Normally keys are not mixed but when they are this is the way it's done.
It's been so for more than a decade so unlikely to change.
These sorters are not used when typesetting because there we also deal
with languages and such. If's mostly a convenience feature that makes
sure we can handles hashes in a predictable order when needed (because
hashes have random order, even per run) and it also tries to be
efficient in doing so.
Hans
-----
Hans Hagen | PRAGMA ADE
Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl
-
___
dev-context mailing list
dev-context@ntg.nl
https://mailman.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] No Official ConTeXt LMTX Repository
On 1/26/2020 6:42 PM, Alan Braslau wrote: On Sat, 25 Jan 2020 23:58:27 +0100 One must not neglect the contributions of many others, including Mojca ... Very true! That also makes it a nice ongoing project. Hans - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl - ___ dev-context mailing list dev-context@ntg.nl https://mailman.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] No Official ConTeXt LMTX Repository
On 1/25/2020 9:23 PM, Sebastian Miele wrote:
In the past months I worked through The TeXbook and The METAFONTbook.
About a week ago I started to work through the LuaMetaTeX manual. For
several reasons I want to learn ConTeXt from bottom to top.
The main page of the ConTeXt Garden says "There is no offical repository
there the development is going." ("there" in that sentence probably
should be "where". I seem to not be allowed to edit the garden main
page.)
The LuaMetaTeX manual contains typos and other issues. In such cases I
usually checkout the most recent development branch of the official
repository and create continually rebased commits on top of it, that
finally find their way into patches send over a mailing list, or pull
requests on e.g. GitHub. This works really well.
Just path the files and mal them to me (as files). I then always compare
them (winmerge) an dso also see if tomething else needs to be changed
(like reformatting the source itself or adding some style related stuff).
Normally the latest context distribution also has the latest sources for
manuals as the distribition gets compiled from several resources (keep
in mind that I can have more files, like todo's and maybe remporary test
files in my working areas).
It would be really cool if ConTeXt LMTX had a/the official repository.
See Mojca's mails ... she has hit all nails.
Hans
-
Hans Hagen | PRAGMA ADE
Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl
-
___
dev-context mailing list
dev-context@ntg.nl
https://mailman.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] Wrong number for previous/next section value
On 1/13/2020 10:01 PM, Wolfgang Schuster wrote:
Hi,
I try to get the counter value of the next section but the result is
always the value for the current section (e.g. section 3 shows also 3 as
value for the next section).
\startbuffer[headnumber]
\starttabulate
\NC first \EQ \somenamedheadnumber {section} {first} \NC\NR
\NC previous \EQ \somenamedheadnumber {section} {previous} \NC\NR
\NC current \EQ \somenamedheadnumber {section} {current} \NC\NR
\NC next \EQ \somenamedheadnumber {section} {next} \NC\NR
\NC last \EQ \somenamedheadnumber {section} {last} \NC\NR
\stoptabulate
\stopbuffer
\starttext
\dorecurse{5}
{\section{Section #1}
\getbuffer[headnumber]}
\stoptext
Also in a second run?
-
Hans Hagen | PRAGMA ADE
Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl
-
___
dev-context mailing list
dev-context@ntg.nl
https://mailman.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] Add headcommand to floatcaption
On 12/25/2019 12:01 AM, Henri Menke wrote:
Dear Hans,
Could you please add the possibility to switch the headcommand to
floatcaption? Below you can find a simple patch that implements what I
am proposing.
Happy holidays,
Henri
---
diff --git a/tex/context/base/mkiv/strc-flt.mkvi
b/tex/context/base/mkiv/strc-flt.mkvi
index 584cf915f..5b0c2d9e5 100644
--- a/tex/context/base/mkiv/strc-flt.mkvi
+++ b/tex/context/base/mkiv/strc-flt.mkvi
@@ -88,6 +88,7 @@
\c!minwidth=\v!fit, % id est: the width of the floatbox in some cases
\c!headstyle=\v!bold,
\c!headcolor=,
+ \c!headcommand=\hbox,
\c!leftmargin=\zeropoint,
\c!rightmargin=\zeropoint,
\c!outermargin=\zeropoint,
@@ -424,7 +425,8 @@
\emptyfloatcaptiontrue
\ifnofloatnumber
\else
-
\hbox{\usefloatcaptionstyleandcolor\c!headstyle\c!headcolor\thecurrentfloatnumber}%
+ \floatcaptionparameter\c!headcommand
+
{\usefloatcaptionstyleandcolor\c!headstyle\c!headcolor\thecurrentfloatnumber}%
\ifnofloatcaption \else \ifemptyfloatcaption \else
\doifelsenothing{\floatcaptionparameter\c!spaceinbetween}
{\floatcaptionparameter\c!headseparator\relax
ok, given an impact approval check by WS
but next time also add an example for the test suite so that we see what
it's meant for
Hans
-
Hans Hagen | PRAGMA ADE
Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl
-
___
dev-context mailing list
dev-context@ntg.nl
https://mailman.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] \textrule and Bidi
On 12/16/2019 10:26 PM, Wolfgang Schuster wrote: A fix for this is to use \naturalvpack instead of \vpack. ok. Hans - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl - ___ dev-context mailing list dev-context@ntg.nl https://mailman.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] pack-lyr.mkiv|mkxl
On 11/30/2019 11:35 AM, Wolfgang Schuster wrote:
Hi,
there is a extra "s" at the end of each \lastnamedcs.
\def\pack_layers_flush_double#1%
{\startoverlay
{\ifcsname\??layerbox\currentlayer\endcsname
- \ifvoid\lastnamedcss\else \chardef\b_layer_two\lastnamedcs
+ \ifvoid\lastnamedcs\else \chardef\b_layer_two\lastnamedcs
\pack_layers_flush_indeed\plusone\currentlayer\b_layer_two
\fi
\fi}%
{\ifcsname\??layerbox\currentlayer:\the\realpageno\endcsname
- \ifvoid\lastnamedcss\else \chardef\b_layer_two\lastnamedcs
+ \ifvoid\lastnamedcs\else \chardef\b_layer_two\lastnamedcs
\pack_layers_flush_indeed\zerocount{\currentlayer:\the\realpageno}\b_layer_two
\fi
\fi}%
{\ifcsname\??layerbox#1\currentlayer\endcsname
- \ifvoid\lastnamedcss\else \chardef\b_layer_two\lastnamedcs
+ \ifvoid\lastnamedcs\else \chardef\b_layer_two\lastnamedcs
\pack_layers_flush_indeed\plusone{#1\currentlayer}\b_layer_two
\fi
\fi}%
{\ifcsname\??layerbox#1\currentlayer:\the\realpageno\endcsname
- \ifvoid\lastnamedcss\else \chardef\b_layer_two\lastnamedcs
+ \ifvoid\lastnamedcs\else \chardef\b_layer_two\lastnamedcs
\pack_layers_flush_indeed\zerocount{#1\currentlayer:\the\realpageno}\b_layer_two
\fi
\fi}%
\stopoverlay}
ah, stupid me ... syntax highlighting should have warned me .. fixed in
next beta
Hans
-
Hans Hagen | PRAGMA ADE
Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl
-
___
dev-context mailing list
dev-context@ntg.nl
https://mailman.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] \doiftext and fallback fonts
On 10/7/2019 11:24 PM, Wolfgang Schuster wrote:
Hi Hans,
the \doiftext(else) command gives a wrong result when the checked
character comes from a fallback font.
\definefontfallback [testfallback] [file:dejavuserif] [greekandcoptic]
\definefontsynonym [FallbackTest] [file:lmroman10-regular]
[fallbacks=testfallback]
\starttext
\definedfont[FallbackTest]
a α % does the fallback work?
\doiftextelse{a}{YES}{NO}
\doiftextelse{α}{YES}{NO}
\stoptext
As a result of this mechanism which use this check like the number
renderer in the section command produce wrong output (missing number in
the section title).
\setuphead [section] [conversion=g]
\definefallbackfamily [mainface] [rm] [DejaVu Serif] [range=greekandcoptic]
\definefontfamily [mainface] [rm] [Latin Modern Roman]
\definefontfamily [mainface] [mm] [Latin Modern Math]
\setupbodyfont [mainface]
\starttext
\placecontent
\section{wow}
\stoptext
ok, so we need
\setbox\scratchbox\hbox % no \hpack because we can have fallbacks
in the checkers
Hans
-
Hans Hagen | PRAGMA ADE
Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl
-
___
dev-context mailing list
dev-context@ntg.nl
https://mailman.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] Typo in generic fontloader code for SVG
On 9/11/2019 12:00 PM, Marcel Fabian Krüger wrote: Hi, in font-ocl.lua, inkscape is called to convert SVG table entries to PDF. This also has a "poor mans variant for generic" around line 464 which is probably supposed to call io.popen, but calls io.open instead. Of course this breaks the conversion and leads to the creation of a weird file. (See https://github.com/latex3/luaotfload/issues/96 for details) Maybe this can be fixed to use `io.popen`? ok There is also a harder to fix issue: Currently the code tries to do the SVG to PDF conversion when caching the font. Especially when shell-escape is disabled, this fails. Now the problem is that in this case rerunning the commands with shell-escape enabled doesn't help because the (empty) cached entries are used. Could you add some logic to try to recreate the cache if the existing PDF cache for a font is empty? i'll see Hans - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl - ___ dev-context mailing list dev-context@ntg.nl https://mailman.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] [NTG-context] type key in \setupattachment
On 6/20/2019 11:01 AM, Taco Hoekwater wrote:
On 20 Jun 2019, at 10:46, Hans Hagen wrote:
On 6/19/2019 9:28 PM, Pablo Rodriguez wrote:
Hi Wolfgang,
Would it be possible that the \setupattachment command has a "type" key
to specify its MIME type? (Default should be "application/octet-stream"
[or so it seems].)
there is a type key
Is that new? It does not seem to be in the xml file?
yes it's new, a couple of months old i think
Hans
-
Hans Hagen | PRAGMA ADE
Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl
-
___
dev-context mailing list
dev-context@ntg.nl
https://mailman.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] Missing indentnext check in buff-ver.mkiv
On 5/27/2019 10:33 PM, Wolfgang Schuster wrote:
Hans Hagen schrieb am 27.05.2019 um 09:42:
On 5/26/2019 11:30 PM, Henri Menke wrote:
Dear devs,
\typebuffer does not obey the indentnext option from \setuptyping
because the corresponding checks are missing in
\buff_verbatim_type_buffer and \buff_verbatim_type_buffer_indeed. I
have attached a possible patch.
ok, added, unless Wolfgang rejects it -)
No objections from my side but shouldn't \typefile also be changed.
so like this:
\else
\buff_verbatim_type_file_checked\v!file{#3}%
\fi\fi
\useindentnextparameter\typingparameter % needs checking
\endgroup
\dorechecknextindentation} % needs checking
i assume Henry has some test file
Hans
-
Hans Hagen | PRAGMA ADE
Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl
-
___
dev-context mailing list
dev-context@ntg.nl
https://mailman.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] Missing indentnext check in buff-ver.mkiv
On 5/26/2019 11:30 PM, Henri Menke wrote: Dear devs, \typebuffer does not obey the indentnext option from \setuptyping because the corresponding checks are missing in \buff_verbatim_type_buffer and \buff_verbatim_type_buffer_indeed. I have attached a possible patch. ok, added, unless Wolfgang rejects it -) Hans - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl - ___ dev-context mailing list dev-context@ntg.nl https://mailman.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] \lastxpos and \lastypos should behave like registers
On 5/23/2019 2:05 AM, Henri Menke wrote: On 23/05/19 11:55 AM, Hans Hagen wrote: On 5/23/2019 1:47 AM, Henri Menke wrote: On 23/05/19 11:36 AM, Hans Hagen wrote: On 5/23/2019 1:11 AM, Henri Menke wrote: Dear devs, The two macros \lastxpos and \lastypos should behave like registers, because that is what they are in LuaTeX. The following MWE fails with ! You can't use `the character 0' after \the \starttext \the\lastxpos \the\lastypos \stoptext A simple fix would be to wrap the macro in \numexpr like in the attached patch. hm, i was actually about to drop them completely ... anyway, i have no problem with the fix but then it also need to be \unexpanded (i'm reshuffling some code so probably no beta for a few days) Dropping \pdflastxpos and \pdflastypos would break TikZ, so it would be good if at least the \lastxpos and \lastypos primitives would be accessible. ok, but i assume that there is no need for the \pdf* ones (because i decided to drop all those specific \pdf* aliases in the next beta ... they were never meant to be persistent part of mkiv) ... i grepped tikz and could not find usage of \pdf... apart from the official luatex ones (actually, tikz is the only package i know that we need to keep an eye on wrt downward compatibility; context modules use different interfaces) You might be happy to hear that I am the current TikZ maintainer, so I can shape it for best interoperability with ConTeXt. ok, so the abstraction layer can be improved a bit then Currently \pdflastpos is only used in one place https://github.com/pgf-tikz/pgf/blob/07959624c5e4c50f80ddf31a3b271885237b37cc/tex/generic/pgf/systemlayer/pgfsys-common-pdf-via-dvi.def#L97-L102 but that can be abstracted. dvi sounds like pdftex being used (or maybe xetex) Hans - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl - ___ dev-context mailing list dev-context@ntg.nl https://mailman.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] \lastxpos and \lastypos should behave like registers
On 5/23/2019 1:47 AM, Henri Menke wrote: On 23/05/19 11:36 AM, Hans Hagen wrote: On 5/23/2019 1:11 AM, Henri Menke wrote: Dear devs, The two macros \lastxpos and \lastypos should behave like registers, because that is what they are in LuaTeX. The following MWE fails with ! You can't use `the character 0' after \the \starttext \the\lastxpos \the\lastypos \stoptext A simple fix would be to wrap the macro in \numexpr like in the attached patch. hm, i was actually about to drop them completely ... anyway, i have no problem with the fix but then it also need to be \unexpanded (i'm reshuffling some code so probably no beta for a few days) Dropping \pdflastxpos and \pdflastypos would break TikZ, so it would be good if at least the \lastxpos and \lastypos primitives would be accessible. ok, but i assume that there is no need for the \pdf* ones (because i decided to drop all those specific \pdf* aliases in the next beta ... they were never meant to be persistent part of mkiv) ... i grepped tikz and could not find usage of \pdf... apart from the official luatex ones (actually, tikz is the only package i know that we need to keep an eye on wrt downward compatibility; context modules use different interfaces) Hans - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl - ___ dev-context mailing list dev-context@ntg.nl https://mailman.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] \lastxpos and \lastypos should behave like registers
On 5/23/2019 1:11 AM, Henri Menke wrote: Dear devs, The two macros \lastxpos and \lastypos should behave like registers, because that is what they are in LuaTeX. The following MWE fails with ! You can't use `the character 0' after \the \starttext \the\lastxpos \the\lastypos \stoptext A simple fix would be to wrap the macro in \numexpr like in the attached patch. hm, i was actually about to drop them completely ... anyway, i have no problem with the fix but then it also need to be \unexpanded (i'm reshuffling some code so probably no beta for a few days) Hans - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl - ___ dev-context mailing list dev-context@ntg.nl https://mailman.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] Interface fails fail to create PDF
On 5/7/2019 9:15 AM, Wolfgang Schuster wrote: Hans Hagen mailto:j.ha...@xs4all.nl>> schrieb am Di., 7. Mai 2019, 09:10: On 5/7/2019 6:42 AM, Wolfgang Schuster wrote: > Hi, > > when I add new commands, options etc. to interface files I often run > context on the file itself to create a PDF to check the content but for > Luametatex this doesn't work anymore. > > > When I run ConTeXt like this > > context i-framed.xml > > I can see ConTeXt creating pages > > mtx-context | jobname: i-framed.xml > mtx-context | ctxname: x-setups.ctx > [...] > pages > flushing realpage 1, userpage 1, subpage 1 > pages > flushing realpage 2, userpage 2, subpage 2 > pages > flushing realpage 3, userpage 3, subpage 3 > pages > flushing realpage 4, userpage 4, subpage 4 > [...] > mkiv lua stats > runtime: 1.146 seconds, 4 processed pages, 4 > shipped pages, 3.490 pages/second > system | total runtime: 1.356 seconds of 1.449 seconds > > but i-framed.pdf is missing in the end. Currently an intermediate file is used, m_k_i_v... is that file present then? No. in back-lpd.lua, can you see what goes on in local function prepare() maybe add some prints ----- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl - ___ dev-context mailing list dev-context@ntg.nl https://mailman.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] Interface fails fail to create PDF
On 5/7/2019 9:10 AM, Hans Hagen wrote:
On 5/7/2019 6:42 AM, Wolfgang Schuster wrote:
Hi,
when I add new commands, options etc. to interface files I often run
context on the file itself to create a PDF to check the content but
for Luametatex this doesn't work anymore.
When I run ConTeXt like this
context i-framed.xml
I can see ConTeXt creating pages
mtx-context | jobname: i-framed.xml
mtx-context | ctxname: x-setups.ctx
[...]
pages > flushing realpage 1, userpage 1, subpage 1
pages > flushing realpage 2, userpage 2, subpage 2
pages > flushing realpage 3, userpage 3, subpage 3
pages > flushing realpage 4, userpage 4, subpage 4
[...]
mkiv lua stats > runtime: 1.146 seconds, 4 processed pages, 4
shipped pages, 3.490 pages/second
system | total runtime: 1.356 seconds of 1.449 seconds
but i-framed.pdf is missing in the end.
Currently an intermediate file is used, m_k_i_v... is that file present
then?
l_m_t_x_*.pdf
-
Hans Hagen | PRAGMA ADE
Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl
-
___
dev-context mailing list
dev-context@ntg.nl
https://mailman.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] Interface fails fail to create PDF
On 5/7/2019 6:42 AM, Wolfgang Schuster wrote:
Hi,
when I add new commands, options etc. to interface files I often run
context on the file itself to create a PDF to check the content but for
Luametatex this doesn't work anymore.
When I run ConTeXt like this
context i-framed.xml
I can see ConTeXt creating pages
mtx-context | jobname: i-framed.xml
mtx-context | ctxname: x-setups.ctx
[...]
pages > flushing realpage 1, userpage 1, subpage 1
pages > flushing realpage 2, userpage 2, subpage 2
pages > flushing realpage 3, userpage 3, subpage 3
pages > flushing realpage 4, userpage 4, subpage 4
[...]
mkiv lua stats > runtime: 1.146 seconds, 4 processed pages, 4
shipped pages, 3.490 pages/second
system | total runtime: 1.356 seconds of 1.449 seconds
but i-framed.pdf is missing in the end.
Currently an intermediate file is used, m_k_i_v... is that file present
then?
Hans
-
Hans Hagen | PRAGMA ADE
Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl
-
___
dev-context mailing list
dev-context@ntg.nl
https://mailman.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] attachments in PDF/A-3
On 4/22/2019 10:32 AM, Pablo Rodriguez wrote: On 4/4/19 1:11 PM, Hans Hagen wrote: On 3/17/2019 4:41 PM, Pablo Rodriguez wrote: - The /AFRelationship key is missing from the /Filespec dictionary (https://github.com/veraPDF/veraPDF-validation-profiles/wiki/PDFA-Parts-2-and-3-rules#rule-68-3). Possible values are: Source, Data, Alternative, Supplement, EncryptedPayload, FormData, Schema or Unspecified (from https://www.pdfa.org/wp-content/uploads/2018/10/PDF20_AN002-AF.pdf). I assume that "Unspecified" is good enough as (1) it's pdf 2.0 and (2) there are probably no viewers out that that use it. Sorry, Hans, but what should be PDF-2.0 the main document or the embedded one? I have no clue. I think PDF 2.0 is basically PDF 1.7 but I wonder if viewers really look at these numbers. Anyway, Unspecified sounds ok to me because otherwise we'd expect users to come up with some dtail that then can conflict with what a viewer at some point in time triggers on. Concerning embedding ... the final document has the version. I suppose an embedded something has it's own namespace and can have any version. I see no reason why a pdf 1.7 document cannot have an embedded 2.0 document, as after all it's just a blob of data. Hans - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl - ___ dev-context mailing list dev-context@ntg.nl https://mailman.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] Quoting problems in grph-con.lua
On 4/21/2019 1:04 PM, Kevin Boulain wrote: I'm a bit reluctant to change this as it can break existing workflows. I understand the motivation but I don't understand the technical reason. This seems to be a simple shell quoting problem to me. I'm an inexperienced ConTeXt/TeX user though, so feel free to tell me I'm utterly wrong :) What if you use "%[oldname]%" and don't feed an quoted argument? I'm not sure I understood: I'm not feeding a quoted argument, grph-con.lua introduces superfluous quotes, breaking the proper quoting introduced later by util-sbx.lua (since the shell is used to spawn the process). Let me try to explain it a little bit better. Ok, but then the issue is not the name only \enabletrackers[sandbox] the sandbox runner always wraps so then we also need to remove quotes in --export-%format%=%newname% and such. (The original runners didn't do escaping.) Hans - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl - ___ dev-context mailing list dev-context@ntg.nl https://mailman.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] Quoting problems in grph-con.lua
On 4/19/2019 9:06 PM, Kevin Boulain wrote:
Hi,
From my understanding, there are some superfluous quotes in
context/base/mkiv/grph-con.lua, cancelling the proper quoting done by
validcommand in context/base/mkiv/util-sbx.lua.
For my document, it tries to run something like (the space in the
'Google Drive' directory breaks the generation):
inkscape ""[...]/Google Drive/[...].svg"" --export-dpi=600
--export-pdf=""[...]/Google Drive/[...].svg.pdf""
Applying this patch fixes the double quotes issue:
local runner = sandbox.registerrunner {
name = "svg to something",
program = "inkscape",
template = longtostring [[
-"%oldname%"
+%oldname%
--export-dpi=%resolution%
---export-%format%="%newname%"
+--export-%format%=%newname%
]],
However, it seems there are more similar quotes in the other templates
of the file.
I'm a bit reluctant to change this as it can break existing workflows.
What if you use "%[oldname]%" and don't feed an quoted argument?
mtx-context | current version: 2019.04.16 08:54
(I hope this is the proper way of reporting.)
Regards.
___
dev-context mailing list
dev-context@ntg.nl
https://mailman.ntg.nl/mailman/listinfo/dev-context
--
-----
Hans Hagen | PRAGMA ADE
Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl
-
___
dev-context mailing list
dev-context@ntg.nl
https://mailman.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] attachments in PDF/A-3
On 3/17/2019 4:41 PM, Pablo Rodriguez wrote: - The /Filespec lacks association with the PDF document or any of its parts, such as pages (https://github.com/veraPDF/veraPDF-validation-profiles/wiki/PDFA-Parts-2-and-3-rules#rule-68-4). From https://www.pdfa.org/wp-content/uploads/2018/10/PDF20_AN002-AF.pdf, it seems that either the /Catalog or a /Page dictionary (there are other ones, but I would limit attachments in ConTeXt to those two [if not to the /Catalog itself only]) should contain an /AF entry with the reference to the /Filespec object(s). I assume that the value type for the /AF entry is an array of one or multiple object references. this is stricky one as some viewers then can end up with duplicate entries in side bars and/or funny scaling of the attachment symbol (at least that is what i remember when looking into it) Hans - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl - ___ dev-context mailing list dev-context@ntg.nl https://mailman.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] proposal for attachments (not restricted to PDF/A)
On 3/24/2019 6:14 PM, Pablo Rodriguez wrote: Hans, I think it would be great to add to all attachments (whether the file is PDF/A or not), the following information in /EmbeddedFile, /Params dictionary (as explained table 46 from page 104 from the PDF spec [https://www.adobe.com/content/dam/acom/en/devnet/pdf/PDF32000_2008.pdf#nameddest=M6.9.25835.Table.caption.wide.Table320.Entries.in.a.Params.dictionary]), the following entries: - /Size - /ModDate - /Subtype with MIME (as already reported). those are relatively easy to add without interference size and date automatically, but type has to be set explicitly, like type=crap and you need to convince wolfgang to add it to the steups Hans - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl - ___ dev-context mailing list dev-context@ntg.nl https://mailman.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] two proposals for attachments in PDF/A-3
On 3/24/2019 6:30 PM, Pablo Rodriguez wrote: Hans, I realized that the values for the /AFRelationship key that I provided in a previous message, are the ones defined for PDF-2.0 (Source, Data, Alternative, Supplement, EncryptedPayload, FormData, Schema or Unspecified). According to https://www.loc.gov/preservation/digital/formats/fdd/fdd000360.shtml, values for the /AFRelationShip key in PDF/A-3 are only: Source, Data, Alternative, Supplement, and Unspecified. If you allow me a suggestion, maybe it would be useful to have two new options in the \setupattachment command: relationship = source data alternative supplement unspecified association = document page The default values could be document and unspecified. The user should know what to do when changing these defaults. Of course, the /AF entry can be placed in other PDF objects, but document and page are enough options to start with. hm, these keys look like rubish to me, do they really serve a purpose? Hans - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl - ___ dev-context mailing list dev-context@ntg.nl https://mailman.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] comment for attachments in PDF/A-3
On 3/20/2019 10:46 PM, Pablo Rodriguez wrote:
Hans,
I have other comments for embedded files, but I need more time to
compose them.
Right now I would like to comment an issue with the following source:
\setupinteraction[state=start]
\starttext
\startTEXpage[offset=1em]
\attachment[/home/ousia/xml-mkiv.pdf]
[name=new-name.pdf,
title=Title,
subtitle=Subtitle,
method=hidden,
author=author]
\stopTEXpage
\stoptext
If method=hidden, a /Names dictionary is added, with the following content:
9 0 obj
<<
/Names [ (/home/ousia/xml-mkiv.pdf) 2 0 R ]
>>
endobj
In some scenarios, this could be a security issue.
Wouldn’t it be possible that the content of the /Names entries would be
replaced by the option keys title or name from \attachment?
could be an option (not that i see a security risk here but flagging
something as a 'security issue' seems to be popular anyway
but ... no changes in that bit of code for the next few weeks as we're
in the tex live code freeze window
Hans
-
Hans Hagen | PRAGMA ADE
Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl
-
___
dev-context mailing list
dev-context@ntg.nl
https://mailman.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] attachments in PDF/A-3
On 3/17/2019 10:51 PM, Pablo Rodriguez wrote: On 3/17/19 10:24 PM, Hans Hagen wrote: On 3/17/2019 4:41 PM, Pablo Rodriguez wrote: [...] These are all the issues veraPDF finds when validating the PDF document generated from the source above. Can you find the place in the official (online) pdf reference (specification) where this is explained? I like to work from that spec. These are the PDF/A version 2 and version 3 specs. They are ISO documents. It is the same thing as with the PDF-2.0 spec. I could relate some of the issues to the PDF-1.7 spec (but /AF and /AFRelationship aren’t part of it), if this made it easier for you. But I’m afraid that the explanations will be part of the PDF/A specifications. so in the end this kind of standardization (whatever purpose it serves) forces dev of free software dev to buy all kind of standards ... i don't like those commercial mix-ups in standards (pdf validation has always been a profitable business so i guess it will stay that way) (the problem with these things is that it doesn't pay of in terms of fun development) Hans - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl - ___ dev-context mailing list dev-context@ntg.nl https://mailman.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] attachments in PDF/A-3
On 3/17/2019 4:41 PM, Pablo Rodriguez wrote:
Dear list,
my sample to add attachments to a PDF/A-3 valid document is the following:
\setuptagging[state=start]
\setupbodyfont[30pt]
\setupbackend
[format=PDF/A-3a,
intent=sRGB IEC61966-2.1,
profile={sRGB.icc,default_gray.icc},
level=0]
\setupcolors[pagecolormodel=auto]
\setupinteraction[state=start]
\starttext
\startTEXpage[offset=1em]
an attachment\attachment[file=xml-mkiv.pdf]
\stopTEXpage
\stoptext
There are five reported errors when tested with the latest development
version of veraPDF (http://downloads.verapdf.org/dev/verapdf-installer.zip):
These are all the issues veraPDF finds when validating the PDF document
generated from the source above.
Can you find the place in the official (online) pdf reference
(specification) where this is explained? I like to work from that spec.
Hans
-
Hans Hagen | PRAGMA ADE
Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl
-
___
dev-context mailing list
dev-context@ntg.nl
https://mailman.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] publ-imp-commands.mkvi
On 3/15/2019 1:05 PM, Wolfgang Schuster wrote: Hi, the following change is needed in the publication file \let\<< -\let\<> +\let\>> ok - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl - ___ dev-context mailing list dev-context@ntg.nl https://mailman.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] strc-ren.mkiv
On 2/27/2019 5:45 PM, Wolfgang Schuster wrote:
Hi Hans,
when you use “text” alternative for \setuphead and enable text
indentation the paragraph after the section title isn’t indented.
\setupindenting[yes,big]
\setuphead[section][alternative=text]
\starttext
\section{Introduction}
\input knuth
\stoptext
This is caused by the \noindentation (needed for the “margintext”
alternative) in \strc_rendering_stop_placement, adding a check for
\headissomewhere fixes it.
\def\strc_rendering_stop_placement
{\n_strc_rendering_hang_lines\zerocount
...
\ifconditional\headisdisplay
\useindentnextparameter\headparameter
\else
- \ignoreparskip
- \noindentation % recently added, was a bug
+ \ifconditional\headissomewhere
+ \ignoreparskip
+ \noindentation
+ \else
+ \ignoreparskip
+ \fi
\fi}
ok, in next zip
-
Hans Hagen | PRAGMA ADE
Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl
-
___
dev-context mailing list
dev-context@ntg.nl
https://mailman.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] i-columns.xml small correction
On 2/5/2019 9:59 PM, Wolfgang Schuster wrote: Hans Hagen schrieb am 05.02.19 um 12:09: On 2/5/2019 11:51 AM, Taco Hoekwater wrote: Hi, In the definition of “setupcolumns”, there are two cd:inherits misrepresented as cd:constants: ok, i'll fix it I have to change the definition of \startcolumns and \setupcolumns because the current descriptions is based on the old code. The current version of the environment is based on the mixedcolumns code which has different options. ok, i'll keep my hands off and assume that new files will show up on the ftp then at some point Hans - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl - ___ dev-context mailing list dev-context@ntg.nl https://mailman.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] spac-hor.mkiv: Missing delimiter for \quad
On 12/27/2018 11:18 AM, Wolfgang Schuster wrote:
Hi Hans,
the definitions for \quad, \qquad and \enskip need a \relax at the end.
- \unexpanded\def\enskip{\hskip.5\emwidth}
- \unexpanded\def\quad {\hskip \emwidth}
- \unexpanded\def\qquad {\hskip 2\emwidth}
+ \unexpanded\def\enskip{\hskip.5\emwidth\relax}
+ \unexpanded\def\quad {\hskip \emwidth\relax}
+ \unexpanded\def\qquad {\hskip 2\emwidth\relax}
indeed
-
Hans Hagen | PRAGMA ADE
Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl
-
___
dev-context mailing list
dev-context@ntg.nl
https://mailman.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] interface file typos and a question
On 12/17/2018 9:29 AM, Taco Hoekwater wrote:
Hi,
Besides those, I also have an actual question:
Is there an intended difference between
and
(cd:instance versus cd:variable)?
I can’t remember the details but with variable the generated commands shows
always
the same name in the output but instance generates a general version of the
command
(which uses slanted uppercase characters, e.g. \FRAMED[..,..=..,..]{...}) and
also
the output for the instances (e.g. \inframed).
The purpose of this is to have one entry for a section types (chapter, section
etc.)
with a single definition while in the past each type had its own entry.
Ah! And those instances are stored in the , I see now. Thanks for
clearing that up.
indeed, the idea was that it saves bytes and prevents errors (omissions)
Hans
-
Hans Hagen | PRAGMA ADE
Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl
-
___
dev-context mailing list
dev-context@ntg.nl
https://mailman.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] x-setups-basics.mkiv
On 11/26/2018 6:50 PM, Wolfgang Schuster wrote:
Hi Hans,
the argument check in \cmd_show_setup_yes has to go away.
\def\cmd_show_setup_yes[#1]%
- {\iffirstargument
- \cmd_show_setup_nop{#1}%
- \else
- \expandafter\cmd_show_setup_nop
- \fi}
+ {\cmd_show_setup_nop{#1}}
ok
-
Hans Hagen | PRAGMA ADE
Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl
-
___
dev-context mailing list
dev-context@ntg.nl
https://mailman.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] tabl-xtb.lua xtables and samepage option
On 11/15/2018 4:25 PM, Wolfgang Schuster wrote: Hi, the samepage option for xtables doesn’t work because of bugs in the Lua code. 1. On line 895 the value has to be taken from the rp-variable itself. 2. On line 905 the second index to get the value for the samepage option is missing. ok .. no beta yet (sometime next week as i'm doing some experiments and in the process reshuffle some lua code) Hans - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl - ___ dev-context mailing list dev-context@ntg.nl https://mailman.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] x-setups-basics.mkiv
On 11/10/2018 12:00 PM, Wolfgang Schuster wrote: Hi Hans, can you add \setupxml[\c!entities=\v!yes] to the module because I need a few entities ( and ) from the extended list. ok - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl - ___ dev-context mailing list dev-context@ntg.nl https://mailman.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] Adding before and after keys to setupcaption
On 10/31/2018 10:24 AM, Aditya Mahajan wrote: Hi Hans, There have been a few questions on TeX.SX asking essentially for a frame around a float that covers both the caption and the content. it's probably a bit more tricky than that ... (also, before/after are sort of taken) i'll send you/wolfgang a variant for testing Hans - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl - ___ dev-context mailing list dev-context@ntg.nl https://mailman.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] meta-imp-txt.mkiv: EnglishRule
On 9/9/2018 6:04 PM, Wolfgang Schuster wrote:
Hi,
the height variable in the EnglishRule graphic needs an assignment,
otherwise you get a error when there is a previous graphic which also
use height as a variable name.
meta-imp-txt.mkiv:
\startuniqueMPgraphic{EnglishRule}{height,width,color}
- height = \MPvar{height} ;
+ height := \MPvar{height} ;
x1 = 0 ; x3 = \MPvar{width} ; x2 = x4 = .5x3 ;
y1 = y3 = 0 ; y2 = -y4 = height/2 ;
fill z1..z2..z3 & z3..z4..z1 & cycle withcolor \MPvar{color} ;
\stopuniqueMPgraphic
or just
\startuniqueMPgraphic{EnglishRule}{height,width,color}
x1 = 0 ; x3 = \MPvar{width} ; x2 = x4 = .5x3 ;
y1 = y3 = 0 ; y2 = -y4 = \MPvar{height}/2 ;
fill z1..z2..z3 & z3..z4..z1 & cycle withcolor \MPvar{color} ;
\stopuniqueMPgraphic
Example (the graphic for the title page in the module documentation uses
height as variable):
\usemodule[module-basic]
\useMPlibrary[txt]
\startdocument
\useMPgraphic{EnglishRule}
\stopdocument
Wolfgang
___
dev-context mailing list
dev-context@ntg.nl
https://mailman.ntg.nl/mailman/listinfo/dev-context
--
-
Hans Hagen | PRAGMA ADE
Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl
-
___
dev-context mailing list
dev-context@ntg.nl
https://mailman.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] User defined environments with parameters
On 8/25/2018 4:36 PM, Wolfgang Schuster wrote: Hi, sometimes one needs a environment where you have to set different strings. While we have \definestartstop to create new environments it doesn’t provide a mechanism to pass values to the environment. Attached is a prototype for such a environment where you can pass values (only style, color and alternative are reserved keys) and create own layouts for the content of each environment. first attempt in strc-usr.mkiv/lua .. just your code but i moved the before and after, added align and tags zip on ftp Hans - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl - ___ dev-context mailing list dev-context@ntg.nl https://mailman.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] lang-ini.mkiv: \startlanguage
On 8/22/2018 9:52 PM, Wolfgang Schuster wrote:
Hi Hans,
can you add a environment version of the \language command.
\unexpanded\def\startlanguage
{\begingroup\language}
\let\stoplanguage\endgroup
Grouped or not? This is also an option:
\unprotect
\unexpanded\def\startlanguage
{\pushmacro\currentlanguage
\lang_basics_set_current}
\unexpanded\def\stoplanguage
{\popmacro\currentlanguage
\lang_basics_set_current[\currentlanguage]}
\protect
-
Hans Hagen | PRAGMA ADE
Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl
-
___
dev-context mailing list
dev-context@ntg.nl
https://mailman.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] language synonyms for registers
On 7/15/2018 5:23 PM, Pablo Rodriguez wrote:
would it be possible to add the following lines to the Greek sorting
rules (in sort-lan.lua)?
definitions['el'] = { parent = 'gr' } -- Greek (ISO 639)
definitions['agr'] = { parent = 'gr' } -- ancient Greek
definitions['grc'] = { parent = 'gr' } -- ancient Greek (ISO 639)
Many thanks for your help,
Depends on Wolfgangs and Thomas assessment.
-
Hans Hagen | PRAGMA ADE
Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl
-
___
dev-context mailing list
dev-context@ntg.nl
https://mailman.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] scrp-ini.mkiv: Global attributes for \setscript command
On 7/9/2018 7:38 PM, Wolfgang Schuster wrote:
There is a typo in typo-dir.mkiv (missing "s" in directions)
\unexpanded\def\setglobaldirection[#1]% todo: symbolic names
{\clf_setdirection#1\relax
- \pickupdirectionattribute}
+ \pickupdirectionsattribute}
Another problem is that you can’t set a global direction because the
command is embedded in \setupdirections.
ok, another attempt ... see typo-dir file
Hans
-
Hans Hagen | PRAGMA ADE
Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl
-
___
dev-context mailing list
dev-context@ntg.nl
https://mailman.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] scrp-ini.mkiv: Global attributes for \setscript command
On 7/9/2018 4:24 PM, Wolfgang Schuster wrote:
Here is the missing example.
\definefontfamily [meiryo] [rm] [Meiryo]
\setupbodyfont[meiryo]
\setlocalscript[nihongo]
%\setglobalscript[nihongo]
\setuplayout[leftmargin=6cm,backspace=7cm,width=middle]
\starttext
\startbuffer[udhr]
All human beings are born free and equal in dignity and rights. They are
endowed with reason and conscience and should act towards one another in
a spirit of brotherhood.
すべての人間は、生まれながらにして自由であり、かつ、尊厳と権利とについて
平等である。人間は、理性と良心とを授けられており、互いに同胞の精神をもっ
て行動しなければならない。
\stopbuffer
\getbuffer[udhr]
Footnote
\startfootnote
\getbuffer[udhr]
\stopfootnote
Margintext\inmargin[style=smallbodyfont]{\getbuffer[udhr]}
\stoptext
i made it a bit more generic ... beta on ftp ... 'pickup' is the magic
word (script and bidi done that way now) .. your example looks ok
Hans
-
Hans Hagen | PRAGMA ADE
Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl
-
___
dev-context mailing list
dev-context@ntg.nl
https://mailman.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] scrp-ini.mkiv: Global attributes for \setscript command
On 7/9/2018 8:57 AM, Wolfgang Schuster wrote:
Hans Hagen <mailto:j.ha...@xs4all.nl>
8. Juli 2018 um 23:02
it needs a bit of thinking (even bidi) ... it compares to global and
local bodyfonts
what if a page break occurs in the middle of japanese local text while
the global script is chinese
I can understand your concerns.
Another way is to add additional commands which let you set the script
for all environments (body text + footnotes).
1. Add "global" to the attribute definition (or add another keyword
which doesn’t add the reset to the local token list but using "global"
should be enough).
%% attr-ini.mkiv
\def\attr_basics_define_indeed#1[#2][#3]%
{\ifcsname\??attributecount#2\endcsname\else
\scratchcounter\clf_defineattribute{#2}{#1}\relax
%\writestatus\m!system{defining #1 attribute #2 with number
\number\scratchcounter}%
\expandafter\attributedef\csname\??attributecount#2\endcsname\scratchcounter
\expandafter\newconstant \csname\??attributeid#2\endcsname
\csname\??attributeid#2\endcsname\scratchcounter
% some attributes are always global
\doifelseinset\s!global{#3}%
{\etoksapp\t_attr_list_global{\csname\??attributecount#2\endcsname\attributeunsetvalue}}%
- {\etoksapp\t_attr_list_local
{\csname\??attributecount#2\endcsname\attributeunsetvalue}}%
+ {\doifnotinset\s!none{#3}
+ {\etoksapp\t_attr_list_local
{\csname\??attributecount#2\endcsname\attributeunsetvalue}}}%
\doifinset\s!nomath{#3}%
{\etoksapp\t_attr_list_nomath{\csname\??attributecount#2\endcsname\attributeunsetvalue}}%
% here public means 'visible' so it's not to be confused with
'public' at the lua end
\doifinset\s!public{#3}%
{\expandafter\let\csname#2\s!attribute\expandafter\endcsname\csname\??attributeid#2\endcsname}%
\fi}
%%
2. Create a flag which can be used to prevent the reset of the
attributes when you use the global-commands. The old \setscript command
will be a synonym for the local settings while you can use the global
command when the document contains only one language.
%% scrp-ini.mkiv
\newconditional\c_scripts_reset \settrue\c_scripts_reset
\appendtoks
\ifconditional\c_scripts_reset
\doresetattribute{scriptinjection}%
\doresetattribute{scriptsplitting}%
\doresetattribute{scriptstatus}%
\fi
\to \t_attr_list_local
%\unexpanded\def\setscript[#1]%
% {\edef\currentscript{#1}%
% \scripts_basics_set}
\unexpanded\def\setlocalscript[#1]%
{\settrue\c_scripts_reset
\edef\currentscript{#1}%
\scripts_basics_set}
\let\setscript\setlocalscript
\unexpanded\def\setglobalscript[#1]%
{\setfalse\c_scripts_reset
\edef\currentscript{#1}%
\scripts_basics_set}
%%
how about this (a bit like languages and bodyfonts)
\unprotect
\newconstant\c_scripts_injection \c_scripts_injection\attributeunsetvalue
\newconstant\c_scripts_splitting \c_scripts_splitting\attributeunsetvalue
\newconstant\c_scripts_status\c_scripts_status \attributeunsetvalue
\unexpanded\def\setglobalscript[#1]%
{\edef\currentscript{#1}%
\scripts_basics_set
\c_scripts_injection\attribute\scriptinjectionattribute
\c_scripts_splitting\attribute\scriptsplittingattribute
\c_scripts_status \attribute\scriptstatusattribute}
\unexpanded\def\setlocalscript[#1]%
{\edef\currentscript{#1}%
\scripts_basics_set}
\let\setscript\setlocalscript
\appendtoks
\attribute\scriptinjectionattribute\c_scripts_injection
\attribute\scriptsplittingattribute\c_scripts_splitting
\attribute\scriptstatusattribute \c_scripts_status
\to \everypagebody
\protect
-
Hans Hagen | PRAGMA ADE
Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl
-
___
dev-context mailing list
dev-context@ntg.nl
https://mailman.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] scrp-ini.mkiv: Global attributes for \setscript command
On 7/8/2018 8:28 PM, Wolfgang Schuster wrote:
Hi Hans,
the \setscript command has the same problem with local attributes as the
bidi mechanism.
Some of the following attributes in scrp-ini.mkiv have to be global:
\definesystemattribute[scriptinjection][public]
\definesystemattribute[scriptsplitting][public]
\definesystemattribute[scriptstatus] [public]
I know "scriptinjection" has to be global to have linebreaks in
footnotes (and margin notes) for chinese and japanese.
I guess "scriptsplitting" has to be global too because it is used for thai.
it needs a bit of thinking (even bidi) ... it compares to global and
local bodyfonts
what if a page break occurs in the middle of japanese local text while
the global script is chinese
Hans
-
Hans Hagen | PRAGMA ADE
Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl
-
___
dev-context mailing list
dev-context@ntg.nl
https://mailman.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] \currentxrow and \currentxcolumn
On 4/12/2018 8:28 PM, Pablo Rodriguez wrote: I wonder whether it would be possible to have \currentxrow and \currentxcolumn for synonyms for \currentxtablerow and \currentxtablecolumn. that's too general and also adds more and more commands (that no one knows of and remembers) you can have a file cont-loc.mkiv in your local tree (texmf-local) that adds all kind of extra commands \let\currentxrow \currentxtablerow \let\currentxcolumn\currentxtablecolumn but then you also need to make sure that it never overloads some core macros (but you can check for that) Hans - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl - ___ dev-context mailing list dev-context@ntg.nl https://mailman.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] scrn-pag.mkiv: Set custom values for the page dimensions
On 3/18/2018 4:58 PM, Wolfgang Schuster wrote:
Hi Hans,
can you add a command to set own values for \clf_setupcanvas, e.g.
\def\scrn_canvas_synchronize_set#1#2%
{\clf_setupcanvas
paperwidth \dimexpr#1\relax
paperheight \dimexpr#2\relax
\relax}
\let\scrn_canvas_synchronize_reset\scrn_canvas_synchronize_only
This is needed for the \pageinjection command when I include larger
images which spread over multiple pages.
So this is for non-interactive mode yes? I think we could do this:
\def\scrn_canvas_synchronize_only
{\clf_setupcanvas
paperwidth \interactionscreenparameter\c!width
paperheight \interactionscreenparameter\c!height
\relax}
as they default to the values that are there now. That way you can use
the width and height parameters of setupinteractionscreen instead of a
low level call.
Or do I misunderstand it.
Hans
-
Hans Hagen | PRAGMA ADE
Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl
-
___
dev-context mailing list
dev-context@ntg.nl
https://mailman.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] fixes for comments in TeX, MP and Lua
On 1/31/2018 7:14 PM, Pablo Rodriguez wrote: Hans, the attached patch comes from code that Christoph Reller kindly provided me with to fix comments in TeX, MP and Lua (https://bitbucket.org/philexander/context-highlight/issues/2/highlight-for-tex). * It formats the whole comment (both character and text [not only the former]) for TeX and MP. * It does the same for one-line comments in Lua. * It fixes multiline comments in Lua. * It fixes a minor typo. The following code is compiled in the PDF attachment that shows the difference before and after the patch: \starttext \startTEX % comment for the whole line \stopTEX \startMP a % comment for the rest of the line \stopMP \startLUA --[[ multiline comment --]] ---[[ multiline but not comment ---]] \stopLUA \stoptext Could you consider merging in ConTeXt? I'll make this: \definestartstop [LuaSnippetCommentText] [color=darkyellow] \definestartstop [TeXSnippetCommentText] [color=darkyellow] \definestartstop [MetapostSnippetCommentText] [color=darkyellow] (not bold by default) - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl - ___ dev-context mailing list dev-context@ntg.nl https://mailman.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] utilities.parsers.stepper
On 1/2/2018 11:35 PM, Wolfgang Schuster wrote: Hi, the function "utilities.parsers.stepper" from util-prs.lua gives me always the following error message when I try one of the examples from the source. in line 609 and 612 remove the C in C(cardinal) because it gives a double capture (probably this code assumes a rather old lpeg) Hans - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl - ___ dev-context mailing list dev-context@ntg.nl https://mailman.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] double widget for signature?
On 12/10/2017 12:55 PM, Pablo Rodriguez wrote: Hans, I have the following sample: \setupinteraction[state=start] \starttext \startTEXpage[offset=1em] \definefield[x][signature] \field[x] \stopTEXpage \stoptext And for the signature two widgets are generated (I include object 7 to make sense of the kids in objet 8): 7 0 obj [ 9 0 R ] endobj 8 0 obj << /DA (/rmtf 11.9552 Tf 1.1955 Ts 0 0 0 rg 0 0 0 RG) /DV /F 4 /FT /Sig /Ff 0 /Kids 7 0 R /MaxLen 1024 /Q 0 /Subtype /Widget /T /V >> endobj 9 0 obj << /Type /Annot /DA (/rmtf 11.9552 Tf 1.1955 Ts 0 0 0 rg 0 0 0 RG) /F 4 /Parent 8 0 R /Q 0 /Subtype /Widget /Rect [ 14.033 14.033 70.404 25.081 ] >> endobj > When Acrobat XI (Win, just in case) signs the document, both widgets are merged into one: 25 0 obj << /AP << /N 14 0 R >> /DA (/rmtf 11.9552 Tf 1.1955 Ts 0 0 0 rg 0 0 0 RG) /DV /F 132 /FT /Sig /Ff 0 /MaxLen 1024 /P 13 0 R /Q 0 /Rect [ 14.033 14.033 464.204 95.701 ] /Subtype /Widget /T /Type /Annot /V 21 0 R >> endobj Would it be possible to generate only one annotation widget for the signature? Only if one beforehand would indicate that there are no more possible kids (we don't want to keep that info as yet another bit of multipass data) which would be yet another hard to explain (undocumented feature). The current approach is afaik valid (and it's already hard enough to get these widgets robust over pdf / acrobat versions). It would also make the code messier (nwo we clearly separate parent and instance, then we have an extra hybrid form which duplicates the code). So, what is the benefit? Saving a few bytes hardly matters here. Hans ----- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl - ___ dev-context mailing list dev-context@ntg.nl https://mailman.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] typo in page-pcl.mkiv
On 11/19/2017 12:10 AM, Pablo Rodriguez wrote: Hans, the attached patch fixes a typo in page-pcl.mkiv. I hope it helps, fixed but don't use that code yet ... it's pretty experimental (i'm moving some experimental code that i used in old styles into the core but it has to be made sort of generic useable) Hans - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl - ___ dev-context mailing list dev-context@ntg.nl https://mailman.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] fix output intent subtype
On 10/24/2017 8:21 PM, Alan Braslau wrote: On Tue, 24 Oct 2017 19:46:21 +0200 luigi scarso <luigi.sca...@gmail.com> wrote: On Tue, Oct 24, 2017 at 7:27 PM, Alan Braslau <braslau.l...@comcast.net> wrote: On Tue, 24 Oct 2017 19:06:51 +0200 luigi scarso <luigi.sca...@gmail.com> wrote: is this \externalfigure[cow] a pdf ? As said previously , including pdf can break the rules of format=PDF/A-3a. Simply include bitmap images, it's way more robust. Isn't that non-optimal, using bitmap images rather than vector graphics? Must there not be a way to correctly include PDF graphics, perhaps modifying the included file to make it conforming? Forgetting for the moment that a generic pdf could not have the right structure (and fix it can be quite complicate) you can have a "guest" pdf file that is valid pdf/a but once included with \externalfigure can conflicts with the "host" pdf, because the host specifies a different color spaces, for example. On the other side, if you include it as bitmap, you are safe on the color spaces and the structure. Of course This sound not ok if the pdf is only text --- but even in this case the situation is not so simple: the fonts must be correct (it's known that we have math fonts that are not ok ), the tounicode also.. so also in this case a high res bitmap can be the only solution., "Let the buyer beware". Given that bitmap graphics are NOT OK (think bloat, an MS/Office specialty), there must be a better solution. Perhaps simply detecting a conflict between an included PDF and the "host" PDF and printing a warning! Then it could be up to the user to "fix" the included PDF so not to break the host PDF. we have a few workflows where we add color profiles to images before inclusion (in fact that's a built in option) but only for bitmap fonts normally a press workflow is cmyk based and vector graphics are then made in cmyk too if someone knows the magic command (gm or gs) to add a color profile to an image i can also add a fixer for it (as we do for bitmaps) but it's always done with external tools Hans (We do have workflows where we manipulate graphics but often these are rather special and it doesn't pay off i.e customers don't want to pay for that and expect it to be, so it even pays off less to then make it into some built-in feature that we need to maintain and document and ...) ----- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl - ___ dev-context mailing list dev-context@ntg.nl https://mailman.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] fix output intent subtype
On 10/23/2017 11:14 PM, Peter Rolf wrote: Am 23.10.2017 um 19:14 schrieb Hans Hagen: On 10/23/2017 7:01 PM, luigi scarso wrote: On Mon, Oct 23, 2017 at 6:25 PM, Pablo Rodriguez <oi...@gmx.es> wrote: Hans, according to Boris Doubrov (one of the developers of the veraPDF parser for PDF/A validation) the subtype of the /OutputIntent dictionary for all PDF/A intents should be GTS_PDFA1 (no GTS_PDFA2 or GTS_PDFA3). Here is his reply for reference: https://github.com/veraPDF/veraPDF-parser/issues/317#issuecomment-338613962. The attached patch fixes the issue. I have tried it myself and it solves the problems with color space profiles. Could you apply it to ConTeXt? Many thanks for your help, sure, but it's better if we have an example that fails --- I mean, the source code, the version of the parser , the command line used. It could be that other parts are also not ok. i also want to check with Peter No objections, the 'gts_flag' is also fix for the PDF/X variants. So all variants get GTS_PDFA1 ? I think I have tested all variants at that time (around Oct 2015) and 'veraPDF' didn't throw an error. Looks like they have improved their parser on that part. Well, for me it means that all that validation esp of keys like this are rather useless (creating work) because docs validated in the past and archived now are suddenly no longer valid. Hans - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl - ___ dev-context mailing list dev-context@ntg.nl https://mailman.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] /MarkInfo refers to empty object
On 10/23/2017 10:07 PM, Pablo Rodriguez wrote: On 10/23/2017 09:53 PM, Hans Hagen wrote: On 10/23/2017 8:40 PM, Pablo Rodriguez wrote: [...] to the new content in beta 2017.10.19 13:50: Marked= lpdf.majorversion == 1 and pdfboolean(true) or nil, for now change that to lpdf.majorversion() Many thanks for your fix, Hans. This is LuajitTeX, Version 1.05.0 (TeX Live 2017) Is this also an issue with more recent LuaTeX versions? Unrelated . The engine as well are context are made ready for pdf version 2 so that's why you get such side effects. The engine is not affected when version 2 is not set. I didn’t know that both LuaTeX and ConTeXt were ready for PDF-2. it looks like viewers don't care much as you can throw a 2.0 version pdf to them Sorry for asking this in the developers’ mailing list, but checking it may be too technical for the standard mailing list. I don't know. PDF issues have been discussed there before. Ok, next time I will only provide patches (the very few I’m able to type) here. just choose the list you think most suitable (often for pdf it helps when more folks test) Hans - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl - ___ dev-context mailing list dev-context@ntg.nl https://mailman.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] /MarkInfo refers to empty object
On 10/23/2017 8:40 PM, Pablo Rodriguez wrote: Dear list, [I accidentally discovered this issue when validating PDF/A documents with veraPDF.] I have the following sample: \nopdfcompression \setuptagging[state=start] \starttext \startTEXpage[offset=1em] \TeX \stopTEXpage \stoptext The resulting PDF document contains a catalog with the entry "/MarkInfo 17 0 R". If compiled with betas up to 2017.10.15 12:29, the PDF object reads: 17 0 obj << /Marked true >> endobj If compiled with betas starting from 2017.10.19 13:50, the PDF object is empty: 17 0 obj << >> endobj Line 153 in lpdf-tag.lua was changed from its original content in beta 2017.10.15 12:29: Marked= pdfboolean(true), to the new content in beta 2017.10.19 13:50: Marked= lpdf.majorversion == 1 and pdfboolean(true) or nil, for now change that to lpdf.majorversion() I wonder whether this may be related to the LuaTeX version. But this is the newest version from the ConTeXt Suite for the Linux 32bit platform (in beta from 17.10.19 13:50): This is LuajitTeX, Version 1.05.0 (TeX Live 2017) Is this also an issue with more recent LuaTeX versions? Unrelated . The engine as well are context are made ready for pdf version 2 so that's why you get such side effects. The engine is not affected when version 2 is not set. Sorry for asking this in the developers’ mailing list, but checking it may be too technical for the standard mailing list. I don't know. PDF issues have been discussed there before. Hans - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl - ___ dev-context mailing list dev-context@ntg.nl https://mailman.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] fix output intent subtype
On 10/23/2017 7:01 PM, luigi scarso wrote: On Mon, Oct 23, 2017 at 6:25 PM, Pablo Rodriguez <oi...@gmx.es> wrote: Hans, according to Boris Doubrov (one of the developers of the veraPDF parser for PDF/A validation) the subtype of the /OutputIntent dictionary for all PDF/A intents should be GTS_PDFA1 (no GTS_PDFA2 or GTS_PDFA3). Here is his reply for reference: https://github.com/veraPDF/veraPDF-parser/issues/317#issuecomment-338613962. The attached patch fixes the issue. I have tried it myself and it solves the problems with color space profiles. Could you apply it to ConTeXt? Many thanks for your help, sure, but it's better if we have an example that fails --- I mean, the source code, the version of the parser , the command line used. It could be that other parts are also not ok. i also want to check with Peter - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl - ___ dev-context mailing list dev-context@ntg.nl https://mailman.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] mathpairs
On 8/5/2017 6:53 AM, Aditya Mahajan wrote: On Sat, 5 Aug 2017, Aditya Mahajan wrote: := \colonequals =: \equalscolon BTW, should we remove the definitions of \colonequals, \equalcolons, and \minuscolon from math-def.mkiv? i'll comment them ... how about the others .. i can make them into virtual characters if needed .. or do they need to be added to unicode (given that we have proof of usage, in that case we can ask barbara) Hans - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl - ___ dev-context mailing list dev-context@ntg.nl https://mailman.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] /UseAttachments and /UseOC for /PageMode
On 5/27/2017 7:01 PM, Pablo Rodriguez wrote: Hans, the attachment contains a patch to be able to set /PageMode to attachments or optional contents. Values are attach and oc. These were the simplest names that came to my mind. What do these keys do? OC is layers (optional content) isn't it? - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl - ___ dev-context mailing list dev-context@ntg.nl https://mailman.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] setup-en.pdf and mkiv command list
On 5/17/2017 8:27 PM, Yu,Jason wrote: I suppose not all abstract commands has tag. For not yet ... it's work in progress, so you can assume tyhat over time the xml file gets more complete - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl - ___ dev-context mailing list dev-context@ntg.nl https://mailman.ntg.nl/mailman/listinfo/dev-context
Re: [dev-context] setup-en.pdf and mkiv command list
On 5/16/2017 2:35 PM, Idris Samawi Hamid ادريس سماوي حامد wrote: On Tue, 16 May 2017 06:27:49 -0600, Idris Samawi Hamid ادريس سماوي حامد <idris.ha...@colostate.edu> wrote: Hi Wolfgang, On Mon, 15 May 2017 13:00:37 -0600, Wolfgang Schuster <schuster.wolfg...@gmail.com> wrote: Hans Hagen <mailto:pra...@wxs.nl> low level is fuzzy anyway: \xmlfirst (more low level?) vs \xmlfilter (more generic) I can add class="system|primitive" (or level="...") to the XML files, commands without attribute are user-level. It would be great to include this system-primitive class in the lexer, but if that's too much of a burden short-term then perhaps we should not wait... Do you have an approximate time-frame for when this can be done? I presume it will take a long time to put that class together... Apologies, got confused, assumed we were talking about low-level context commands, not TeX/luaTeX primitives. sure, but a categorization has to cover all aspects of tex Hans - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl - ___ dev-context mailing list dev-context@ntg.nl https://mailman.ntg.nl/mailman/listinfo/dev-context
