Re: [NTG-context] TeX's \downbracefill and \upbracefill
Am Tue, Oct 12, 2021 at 01:24:29PM +0200 schrieb Hans Hagen:
> On 10/12/2021 7:47 AM, Rudolf Bahr via ntg-context wrote:
> >
> >
> > Hello to all,
> >
> > in Knuth's "The TeXbook" page 225/226 (excerpt is appended here) braces
> > are to be seen which I'd need to typeset a genealogical table.
> >
> > Now, the commands \downbracefill and \upbracefill are no context commands.
> > Please, are there correspondings to them?
> $\overbrace{\hbox{}}$
>
> \mathematics{\overbrace{\hbox{}}}
It works well. Thank you, Hans!
Rudolf
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://context.aanhet.net
archive : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___
Re: [NTG-context] Converting LaTeX math to ConTeXt
On Tue, 12 Oct 2021, Jason Ross wrote: > > > On 10/11/21 4:02 PM, Aditya Mahajan wrote: > > You can use pandoc to parse latex and convert it to mathml: > > > > Processing this in context (see attached files), gives a partially working > > solution. It doesn't look okay, but should be easily fixable. > > > > Do note that this is almost same as compiling latex output to PDF because > > editing presentation mathml by hand is no fun. > > Hmm. Looks like converting to MathML isn't going to work just yet. > Is this an issue with ConTeXt? The MathML seems to render correctly in > LibreOffice but gets mangled when exporting to ConTeXt. This is an issue with ConTeXt, but most of these issues are minor are easy to fix. Just send minimal examples showing the incorrect rendering. Aditya ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://context.aanhet.net archive : https://bitbucket.org/phg/context-mirror/commits/ wiki : http://contextgarden.net ___
Re: [NTG-context] Converting LaTeX math to ConTeXt
On 10/11/21 4:02 PM, Aditya Mahajan wrote: You can use pandoc to parse latex and convert it to mathml: Processing this in context (see attached files), gives a partially working solution. It doesn't look okay, but should be easily fixable. Do note that this is almost same as compiling latex output to PDF because editing presentation mathml by hand is no fun. Hmm. Looks like converting to MathML isn't going to work just yet. Is this an issue with ConTeXt? The MathML seems to render correctly in LibreOffice but gets mangled when exporting to ConTeXt. I'll explore some of the alternatives you suggested. A simple parser will be fine for now. Thank you the help. Best Regards, Jason ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://context.aanhet.net archive : https://bitbucket.org/phg/context-mirror/commits/ wiki : http://contextgarden.net ___
Re: [NTG-context] body text and footnote space
Ah, I see the latest is 10 Oct. Mine is 17 September, so I'll upgrade and see the difference, hopefully. Thanks Julian On 12/10/21 10:25 pm, Hans Hagen wrote: On 10/12/2021 3:09 AM, jbf via ntg-context wrote: Dear list, I note previous discussions on the matter of body text invading footnote space (as late as last year). As I am currently typesetting a 400 plus page academic text with hundreds of footnotes, and do not have the option of making them endnotes, I am facing this issue page after page. The only solution I have for now is to make per page layout adjustments to reduce a line or two, so there is a way to handle it, but given ConTeXt's 'perfection' generally, I would be very interested to know if there is any other solution forthcoming. I've tried various options in \setupfootnotes and \setuptolerance', but to no avail. Is this still the case in the latest version? 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 - ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://context.aanhet.net archive : https://bitbucket.org/phg/context-mirror/commits/ wiki : http://contextgarden.net ___
Re: [NTG-context] Bloody PDF boxes and cr*p marks!
On 10/12/2021 6:18 PM, Henning Hraban Ramm via ntg-context wrote:
Am 12.10.2021 um 13:15 schrieb Hans Hagen :
On 10/12/2021 12:36 PM, Henning Hraban Ramm via ntg-context wrote:
Comrades!
There must have been a time when PDF boxes (i.e. CropBox, TrimBox, BleedBox)
worked as they should, but it must have been a short time.
I long ago lost track of what all that means ... decades of pdf ... different
viewers, different interpretations ... validators complaining about things
missing ... i guess that bit (like annotations) will always be in flux (also
because specs came before implementations i guess).
Hm, you implemented these boxes only in 2015, there was not much change in that
regard since then.
Way earlier but it wasn't enabled ... (I'm not going to check ancient
tex live dvd's).
addtopageattributes("CropBox",box) -- mandate for rendering
addtopageattributes("TrimBox",box) -- mandate for pdf/x
-- addtopageattributes("BleedBox",box)
-- addtopageattributes("ArtBox",box)
I remember discussing it with (I think) Pablo and it definityely came up
when we were dealing with these 'standards'.
* BleedBox must be TrimBox plus bleed.
a relative new one, probably also sensitive for interpretation by renderer, imo
worthless
Not worthless; workflow systems in printshops rely on BleedBox and TrimBox.
It’s not about rendering, but imposition and even postprocessing (cutting etc.).
* ArtBox is neglectable for whole layouts (same as TrimBox might make sense),
just interesting in \externalfigure.
also worthless
I agree.
With
\setuppaper[A4][A4,oversized]
I’d expect ConTeXt to set...
* MediaBox and CropBox to the bigger format
* TrimBox to the page format (A4)
* BleedBox also to the page format, while no bleed is defined
well, that's an assumption ... who knows what a printer (driver) does ...
Who sends PDF files directly to a printer (driver)? I know it only from
automated, professional workflows.
Usually printer drivers gets fed by PDF viewers, and I know none that even
*can* print something different than CropBox.
afaik some printers accept pdf (hard to check) but I the fact that a
viewer does something doesn't mean it did years ago (just like at how
crippled tounicode has been / is supported over time)
Beware, \setupbleeding refers only to stretching of images (\externalfigure)!
fwiw, that bleeding options is mostly there to communicate with mp
Good to know. I just browsed the Details manual, didn’t try it yet, since I
scale and move my “bleeding” images differently.
i actually need to pick up that bit ... (some code in my local styles i
need to check) because it can be handy for cover pages (but then i also
need to check if i don't break something
* to define trimoffset, I must know the difference between paper size and sheet size
("oversized" adds 15 mm).
oversized is a convenience feature, in prepress one would define a real, target
size, not rely on a convenience value
But it’s convenient ;) I usually just need a format that is big enough for the
crop marks, and “oversized” does that.
sure, i use it too
% ... and no dependency on interactionscreen!
that's a historic fact ... special pdf features triggered by that command ..
basically tex only has a page size
Of course, but it doesn’t make sense any more, and defining the boxes wouldn’t
hurt anyone. (I’m quite sure, but let them beat me ;))
maybe, but it's also a bit about otr/backend timing, so i need to sit
down on it
Yes, that would mean a backward incompatible change. But how many of us rely on
the strange current behavior?
Please let us fix this!
the problem is as usual documentation and indeed we can have some backward
compatibility issue here ... i honestly have no clue how viewers and printers
react (so if something would be added/changed it would be option driven)
I wouldn’t expect printers (office printing devices) to react at all; I hope
that printers (printshop workers) will react positively to correct boxes in our
PDFs ;)
oh, i'm often surprised about printing houses .. (the best were some
comment on a file having rgb bitmaps while it actually had cmyk outlines
and validators/fixers inlining xforms while setting lines to 0pt widths)
.. and some still use acrobat 4 -)
In some cases it makes sense to have different values on e.g. inner and outer
edges; I feat that would add a plethora of additional parameters
(leftbleedoffset, innerbleedoffset...).
Maybe give a list like in CSS? bleedoffset={3mm,3mm,3mm,0mm} – top, right,
bottom, left order implied; not very “ConTeXt style”.
probably spreads need some treatment (imposition)
Multiple pages on a sheet are not considered by the PDF specs.
yes but what of context imposes
(i'm pretty sure that changes will themselves introduce new issues)
Probable.
anyway, we can look at it once we're all on lmtx because i'm not going to
change mkiv in that aspect
Ok
remind me in a few months (it's a
Re: [NTG-context] Outlined text (from MP) inline in ConText has incorrect baseline (i.e. no depth)
Ok, now that I've had some time to experiment with effects and attributes,
here's what I ended up with. It uses an overlaid double draw to create outlined
text with optional fill (white), border (black). I've only tested it with words
so haven't worked out how it could be adapted to support longer strings (e.g.
the \hbox+\rlap hack likely will disappoint/fail in that case). For parameter
simplicity, I don't allow specifying the outline width separately; but that
might be another good exercise to use key–value parameters instead.
Thanks for the help,
---K
% \OutlinedText[fill][outline]{text}
\def\OutlinedText{\dodoubleempty\doOutlinedText}
\def\doOutlinedText[#1][#2]#3%
{%
\ifsecondargument
\makeOutlinedText{#1}{#2}{#3}%
\else\iffirstargument
\makeOutlinedText{#1}{black}{#3}%
\else
\makeOutlinedText{white}{black}{#3}%
\fi\fi
}
\defineeffect[OuterEffect][alternative=outer,rulethickness=0.1pt]
\defineeffect[InnerEffect][alternative=inner,rulethickness=0.1pt]
\def\makeOutlinedText#1#2#3%
{%
\hbox%
{%
\rlap{\color[#1]{\effect[InnerEffect]{#3}}}%
\color[#2]{\effect[OuterEffect]{#3}}%
}%
\autoinsertnextspace
}
%%
\starttext
\OutlinedText[red][yellow]{Arguments: red yellow \ldots}\\
\OutlinedText[red]{Arguments: red \ldots}
\OutlinedText{Arguments: \ldots}\\
\stoptext
Kevin W. Rudd, Ph.D.
CAPT, USN (Ret)
Computer Architecture & Computer Engineering
Advanced Computing Systems (ACS) Research Program
Laboratory for Physical Sciences (LPS)
443-654-7878
ke...@lps.umd.edu
Visiting Research Professor
United States Naval Academy
r...@usna.edu
On Oct 8, 2021, at 07:36, Hans Hagen
mailto:j.ha...@xs4all.nl>> wrote:
On 10/7/2021 4:14 PM, Rudd, Kevin via ntg-context wrote:
Hey---
I'm trying to insert outlined text (derived from MetaFun example code) into a
document and it seems to work up to the point that the text has depth
(descenders). There's a previous post that mentions using textcommand for
titles to ensure that the appropriate baseline is used but I haven't figured
out why that would work; for my purposes, I'm insert the text inline so that
solution wouldn't work here. I have included a MWE that demonstrates the
problem; I've tried putting both the text and the outlined text in a box, then
adjusting the outlined text by the depth of the text itself but that doesn't
seem to work. I expect that there's an easy way either in MP or ConTeXt, but I
haven't found it yet.
% \OutlinedText[glyph][outline]{text}
\def\OutlinedText{\dodoubleempty\doOutlinedText}
\def\doOutlinedText[#1][#2]#3%
{%
% \type{#1}::\type{#2}::\type{#3}
\ifsecondargument
\makeOutlinedText{#1}{#2}{#3}%
\else\iffirstargument
\makeOutlinedText{#1}{black}{#3}%
\else
\makeOutlinedText{white}{black}{#3}%
\fi\fi
}
\def\makeOutlinedText#1#2#3%
{%
\startMPcode
draw outlinetext.b("#3")
(withcolor "#1")
(withcolor "#2" withpen pencircle scaled 1/16);
\stopMPcode
\autoinsertnextspace
}
\starttext
start
\OutlinedText{aaa}
and \OutlinedText{Bbb}
and \OutlinedText{ggg}
and \OutlinedText{Yyy}
finish
\stoptext
(Here is the code with my attemps to shift the baseline; the \dp & \wd approach
seems to do nothing, and the \lower doesn't compile and I haven't pursued why
yet.)
% \def\makeOutlinedText#1#2#3%
% {%
% \newbox\tBox
% \newbox\uBox
% \setbox\tBox\hbox{#3}
% \setbox\uBox
% \hbox{%
% \startMPcode
% draw outlinetext.b("#3")
% (withcolor "#1")
% (withcolor "#2" withpen pencircle scaled 1/16);
% \stopMPcode
% }%
% % \lower\uBox\dp\tBox
% \ht\uBox=\ht\tBox
% \dp\uBox=\dp\tBox
% \unbox\uBox
% \autoinsertnextspace
}
Any feedback or suggestions would be appreciated.
\defineeffect[MyEffect][alternative=outer,rulethickness=.1pt]
\starttext
start
{\effect[MyEffect]{aaa}} \OutlinedText{aaa}
and {\red \effect[MyEffect]{Bbb}} \OutlinedText{Bbb}
and {\green\effect[MyEffect]{ggg}} \OutlinedText{ggg}
and {\blue \effect[MyEffect]{Yyy}} \OutlinedText{Yyy}
finish
\stoptext
Kevin W. Rudd, Ph.D.
CAPT, USN (Ret)
Computer Architecture & Computer Engineering
Advanced Computing Systems (ACS) Research Program
Laboratory for Physical Sciences (LPS)
443-654-7878
ke...@lps.umd.edu
Visiting Research Professor
United States Naval Academy
Re: [NTG-context] Bloody PDF boxes and cr*p marks!
> Am 12.10.2021 um 13:15 schrieb Hans Hagen :
>
> On 10/12/2021 12:36 PM, Henning Hraban Ramm via ntg-context wrote:
>> Comrades!
>> There must have been a time when PDF boxes (i.e. CropBox, TrimBox, BleedBox)
>> worked as they should, but it must have been a short time.
>
> I long ago lost track of what all that means ... decades of pdf ... different
> viewers, different interpretations ... validators complaining about things
> missing ... i guess that bit (like annotations) will always be in flux (also
> because specs came before implementations i guess).
Hm, you implemented these boxes only in 2015, there was not much change in that
regard since then.
>> * BleedBox must be TrimBox plus bleed.
>
> a relative new one, probably also sensitive for interpretation by renderer,
> imo worthless
Not worthless; workflow systems in printshops rely on BleedBox and TrimBox.
It’s not about rendering, but imposition and even postprocessing (cutting etc.).
>> * ArtBox is neglectable for whole layouts (same as TrimBox might make
>> sense), just interesting in \externalfigure.
>
> also worthless
I agree.
>> With
>> \setuppaper[A4][A4,oversized]
>> I’d expect ConTeXt to set...
>> * MediaBox and CropBox to the bigger format
>> * TrimBox to the page format (A4)
>> * BleedBox also to the page format, while no bleed is defined
>
> well, that's an assumption ... who knows what a printer (driver) does ...
Who sends PDF files directly to a printer (driver)? I know it only from
automated, professional workflows.
Usually printer drivers gets fed by PDF viewers, and I know none that even
*can* print something different than CropBox.
>> Beware, \setupbleeding refers only to stretching of images (\externalfigure)!
>
> fwiw, that bleeding options is mostly there to communicate with mp
Good to know. I just browsed the Details manual, didn’t try it yet, since I
scale and move my “bleeding” images differently.
>> * to define trimoffset, I must know the difference between paper size and
>> sheet size ("oversized" adds 15 mm).
>
> oversized is a convenience feature, in prepress one would define a real,
> target size, not rely on a convenience value
But it’s convenient ;) I usually just need a format that is big enough for the
crop marks, and “oversized” does that.
>> % ... and no dependency on interactionscreen!
>
> that's a historic fact ... special pdf features triggered by that command ..
> basically tex only has a page size
Of course, but it doesn’t make sense any more, and defining the boxes wouldn’t
hurt anyone. (I’m quite sure, but let them beat me ;))
>> Yes, that would mean a backward incompatible change. But how many of us rely
>> on the strange current behavior?
>> Please let us fix this!
>
> the problem is as usual documentation and indeed we can have some backward
> compatibility issue here ... i honestly have no clue how viewers and printers
> react (so if something would be added/changed it would be option driven)
I wouldn’t expect printers (office printing devices) to react at all; I hope
that printers (printshop workers) will react positively to correct boxes in our
PDFs ;)
>> In some cases it makes sense to have different values on e.g. inner and
>> outer edges; I feat that would add a plethora of additional parameters
>> (leftbleedoffset, innerbleedoffset...).
>> Maybe give a list like in CSS? bleedoffset={3mm,3mm,3mm,0mm} – top, right,
>> bottom, left order implied; not very “ConTeXt style”.
> probably spreads need some treatment (imposition)
Multiple pages on a sheet are not considered by the PDF specs.
> (i'm pretty sure that changes will themselves introduce new issues)
Probable.
> anyway, we can look at it once we're all on lmtx because i'm not going to
> change mkiv in that aspect
Ok
Hraban
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://context.aanhet.net
archive : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___
Re: [NTG-context] combination with lua
Thank you Hans and Wolfgang for the explanation!
Adam
On Tue, Oct 12, 2021 at 4:22 PM Wolfgang Schuster <
wolfgang.schuster.li...@gmail.com> wrote:
> Hans Hagen via ntg-context schrieb am 12.10.2021 um 14:12:
> > On 10/11/2021 1:38 PM, Adam Reviczky via ntg-context wrote:
> >> Hi,
> >>
> >> I am trying to use a combination figure with luacode (both with
> >> latest MKIV and LMTX).
> >> However, the figures do not line up in the grid of the combination.
> >>
> >> I get the correct result with examples 1 and 2 below, but example 3
> >> using lua functions for combination and externalfigure is what I
> >> wanted to use in the first place.
> >>
> >> MWE:
> >>
> >> \starttext
> >>
> >> \startluacode
> >>
> >> -- Combination 1
> >> context.startplacefigure({title = "Figure"})
> >> context.startcombination({nx = "2", ny = "2"},
> >>
> >> "\\externalfigure[cow][width=50mm]","Caption 1",
> >> "\\externalfigure[cow][width=50mm]","Caption 2",
> >> "\\externalfigure[cow][width=50mm]","Caption 3",
> >> "\\externalfigure[cow][width=50mm]","Caption 4"
> >> )
> >>
> >> context.stopcombination()
> >> context.stopplacefigure()
> >>
> >> -- Combination 2
> >>
> >> context.startplacefigure({title = "Figure"})
> >> context.startcombination({nx = "2", ny = "2"},
> >>
> >> "Picture 1","Caption 1",
> >> "Picture 2","Caption 2",
> >> "Picture 3","Caption 3",
> >> "Picture 4","Caption 4"
> >> )
> >>
> >> context.stopcombination()
> >> context.stopplacefigure()
> >>
> >> -- Combination 3
> >>
> >> context.startplacefigure({title = "Figure"})
> >> context.startcombination({nx = "2", ny = "2"},
> >>
> >> context.externalfigure({"cow"},{width = "50mm"}),"Caption 1",
> >> context.externalfigure({"cow"},{width = "50mm"}),"Caption 2",
> >> context.externalfigure({"cow"},{width = "50mm"}),"Caption 3",
> >> context.externalfigure({"cow"},{width = "50mm"}),"Caption 4"
> >> )
> >>
> >> context.stopcombination()
> >> context.stopplacefigure()
> >>
> >> \stopluacode
> >> \stoptext
> >>
> >> Any hints on what I am doing wrong in example 3?
> > as in any prodedural language a function as argument gets immediately
> > executed so you need to delay:
> >
> > context.startplacefigure({title = "Figure"})
> > context.startcombination({nx = "2", ny = "2"},
> > context.delayed.externalfigure({"cow"},{width = "50mm"}),
> > "Caption 1",
> > context.delayed.externalfigure({"cow"},{width = "50mm"}),
> > "Caption 2",
> > context.delayed.externalfigure({"cow"},{width = "50mm"}),
> > "Caption 3",
> > context.delayed.externalfigure({"cow"},{width = "50mm"}),
> > "Caption 4"
> > )
> > context.stopcombination()
> > context.stopplacefigure()
> >
> > (this is why encoding complex documents completely in a scrtipt
> > language is non trivial and why for instance these template systems
> > are there because these accumulate)
>
> Another solution is to use the content and caption blocks for each
> combination entry.
>
> \starttext
>
> \startluacode
>
> context.startplacefigure({title = "Figure"})
> context.startcombination({nx = 1, ny = 1})
> context.startcontent()
> context.externalfigure({"cow"},{width = "50mm"})
> context.stopcontent()
> context.startcaption()
> context("Caption 1")
> context.stopcaption()
> context.stopcombination()
> context.stopplacefigure()
>
> \stopluacode
>
> \stoptext
>
> Wolfgang
>
>
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://context.aanhet.net
archive : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___
Re: [NTG-context] combination with lua
Hans Hagen via ntg-context schrieb am 12.10.2021 um 14:12:
On 10/11/2021 1:38 PM, Adam Reviczky via ntg-context wrote:
Hi,
I am trying to use a combination figure with luacode (both with
latest MKIV and LMTX).
However, the figures do not line up in the grid of the combination.
I get the correct result with examples 1 and 2 below, but example 3
using lua functions for combination and externalfigure is what I
wanted to use in the first place.
MWE:
\starttext
\startluacode
-- Combination 1
context.startplacefigure({title = "Figure"})
context.startcombination({nx = "2", ny = "2"},
"\\externalfigure[cow][width=50mm]","Caption 1",
"\\externalfigure[cow][width=50mm]","Caption 2",
"\\externalfigure[cow][width=50mm]","Caption 3",
"\\externalfigure[cow][width=50mm]","Caption 4"
)
context.stopcombination()
context.stopplacefigure()
-- Combination 2
context.startplacefigure({title = "Figure"})
context.startcombination({nx = "2", ny = "2"},
"Picture 1","Caption 1",
"Picture 2","Caption 2",
"Picture 3","Caption 3",
"Picture 4","Caption 4"
)
context.stopcombination()
context.stopplacefigure()
-- Combination 3
context.startplacefigure({title = "Figure"})
context.startcombination({nx = "2", ny = "2"},
context.externalfigure({"cow"},{width = "50mm"}),"Caption 1",
context.externalfigure({"cow"},{width = "50mm"}),"Caption 2",
context.externalfigure({"cow"},{width = "50mm"}),"Caption 3",
context.externalfigure({"cow"},{width = "50mm"}),"Caption 4"
)
context.stopcombination()
context.stopplacefigure()
\stopluacode
\stoptext
Any hints on what I am doing wrong in example 3?
as in any prodedural language a function as argument gets immediately
executed so you need to delay:
context.startplacefigure({title = "Figure"})
context.startcombination({nx = "2", ny = "2"},
context.delayed.externalfigure({"cow"},{width = "50mm"}),
"Caption 1",
context.delayed.externalfigure({"cow"},{width = "50mm"}),
"Caption 2",
context.delayed.externalfigure({"cow"},{width = "50mm"}),
"Caption 3",
context.delayed.externalfigure({"cow"},{width = "50mm"}),
"Caption 4"
)
context.stopcombination()
context.stopplacefigure()
(this is why encoding complex documents completely in a scrtipt
language is non trivial and why for instance these template systems
are there because these accumulate)
Another solution is to use the content and caption blocks for each
combination entry.
\starttext
\startluacode
context.startplacefigure({title = "Figure"})
context.startcombination({nx = 1, ny = 1})
context.startcontent()
context.externalfigure({"cow"},{width = "50mm"})
context.stopcontent()
context.startcaption()
context("Caption 1")
context.stopcaption()
context.stopcombination()
context.stopplacefigure()
\stopluacode
\stoptext
Wolfgang
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://context.aanhet.net
archive : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___
[NTG-context] Solved: Making metafun pictures fainter
Hi List, Thanks, Hans, for your suggestion. In the end, I decided that I actually liked the silhouettes better than a faint version of the whole picture. Silhouettes clearly show the motion, but are far less visually distracting. In the figure below, the projectile motion’s are clear, including the cow’s constant angular velocity, but the final state still pops out. Gracht.pdf Description: Adobe PDF document I used “redecorated" to get the pictures with light, solid grays. Below is code for producing just the ball, if anyone wants to see the details. It includes a simple “shadow" macro that produces a shadow of any picture with an adjustable gray. I’m having lots of metafun! Gavin \startMPinclusions picture ball; ball := image( fill fullcircle scaled 1cm withshademethod "circular" withshadecenter (.25,.25) withshadecolors (.8white, black); draw fullcircle scaled 1cm withpen pencircle scaled 0.8pt ;); vardef shadow(expr p, t) = draw redecorated (draw p) withcolor t[background,0.8background]; enddef; \stopMPinclusions \startMPpage pair p; for i=0 upto 10: p := (i*cm/10, -((i-7.33)**2)*cm/7); shadow(ball shifted p, (i+1)/10) ; endfor draw ball shifted(1.1cm, -1.92cm) ; \stopMPpage > On Oct 11, 2021, at 2:53 AM, Hans Hagen wrote: > > On 10/11/2021 6:30 AM, Gavin via ntg-context wrote: >> Hi List, >> I made good progress producing fainter pictures in metafun. Here is a >> uniformly accelerated cow in the style of my book. >> I abandoned transparency, since I actually don’t want to see through >> anything. I am using uncolored to get the fade. It works great with a >> picture that is made with fill and draw, but it doesn’t work with shading. >> The example below has a flat disk and a round ball. The disk looks fine, but >> the shaded ball is not surviving the application of inverted / uncolored. >> \startMPinclusions >> picture disk, ball; >> disk := image( >> fill fullcircle scaled 1cm withcolor .4white; >> draw fullcircle scaled 1cm withpen pencircle scaled 0.8pt ;); >> ball := image( >> fill fullcircle scaled 1cm >> withshademethod "circular" >> withshadecenter (.25,.25) >> withshadecolors (.8white, black); >> draw fullcircle scaled 1cm withpen pencircle scaled 0.8pt ;); >> \stopMPinclusions >> \startMPpage >>draw inverted (disk uncolored .1white) ; >>draw inverted (disk uncolored .2white) shifted (0.25cm,0) ; >>draw inverted (disk uncolored .5white) shifted (1cm,0) ; >>draw disk shifted (2.25cm,0) ; >>draw inverted (ball uncolored .1white) shifted (0, -2cm) ; >>draw inverted (ball uncolored .2white) shifted (0.25cm, -2cm) ; >>draw inverted (ball uncolored .5white) shifted (1cm, -2cm) ; >>draw ball shifted (2.25cm, -2cm) ; >> \stopMPpage >> Same result in LMTX and MkIV. (ConTeXt ver: 2021.09.17 10:01 LMTX fmt: >> 2021.9.21 int: english/english) >> I’m pretty happy with this uncolored trick, and will be even happier if I >> can get it to work with the shadings. >> Any suggestions? > \startMPpage >fill fullcircle scaled 10cm >shifted (3cm,0) >withcolor white ; >fill fullcircle scaled 10cm >shifted (3cm,0) >withcolor black >withtransparency (1,.25) ; > >fill fullcircle scaled 5cm >shifted (3cm,0) >withcolor .25[red,white] ; > \stopMPpage > > > - > Hans Hagen | PRAGMA ADE > Ridderstraat 27 | 8061 GH Hasselt | The Netherlands > tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl > - ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://context.aanhet.net archive : https://bitbucket.org/phg/context-mirror/commits/ wiki : http://contextgarden.net ___
Re: [NTG-context] Clickable url problem with \useurl and \url
On 10/12/2021 03:44, Taco Hoekwater wrote:
Hi,
On 12 Oct 2021, at 04:30, Rik Kabel via ntg-context wrote:
Hello List,
I notice an inconsistency in the clickable area when using \useurl. With the
following example, both the \from and the \url are clickable in some lines (as
noted iin the value of \from) but in others, the \from is clickable but not the
\url.
It does seem sensitive to the urlL, but I cannot see a pattern.
It is the pdf viewer program that automatically interprets the \url-produced
text and 'invents' a link, it is not
ConTeXt itself. The exact rules may therefore vary depending on the pdf viewer
you use.
In Apple's Preview, all items are in fact clickable. But only \from produces
actual pdf hyperlink annotations.
Should I use something other than \url[earlXX] here to get the clickable
literal url from useurl?
This, maybe
\goto{\url[earlLH]}[url(earlLH)]
(perhaps wrapped in a short macro)
Best wishes,
Taco
—
Taco Hoekwater E: t...@bittext.nl
genderfluid (all pronouns)
Indeed, that is the issue. I use Sumatra by default, but I see different
results with other viewers. I will follow up, if needed, elsewhere.
And yes, for consistency I will look at something based on \goto to make
explicit what should and should not be clickable.
Thank you for the explanation and suggestion.
--
Rik
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://context.aanhet.net
archive : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___
Re: [NTG-context] body text and footnote space
> Am 12.10.2021 um 13:25 schrieb Hans Hagen via ntg-context > : > > On 10/12/2021 3:09 AM, jbf via ntg-context wrote: >> Dear list, >> I note previous discussions on the matter of body text invading footnote >> space (as late as last year). As I am currently typesetting a 400 plus page >> academic text with hundreds of footnotes, and do not have the option of >> making them endnotes, I am facing this issue page after page. The only >> solution I have for now is to make per page layout adjustments to reduce a >> line or two, so there is a way to handle it, but given ConTeXt's >> 'perfection' generally, I would be very interested to know if there is any >> other solution forthcoming. I've tried various options in \setupfootnotes >> and \setuptolerance', but to no avail. > Is this still the case in the latest version? In my projects it looks good with the latest LMTX. Hraban ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://context.aanhet.net archive : https://bitbucket.org/phg/context-mirror/commits/ wiki : http://contextgarden.net ___
[NTG-context] Solved: Making metafun pictures fainter
Hi List,Thanks, Hans, for your suggestion. In the end, I decided that I actually liked the silhouettes better than a faint version of the whole picture. Silhouettes clearly show the motion, but are far less visually distracting. In the figure below, the projectile motion’s are clear, including the cow’s constant angular velocity, but the final state still pops out. Gracht.pdf Description: Adobe PDF document I used “redecorated" to get the pictures with light, solid grays. Below is code for producing just the ball, if anyone wants to see the details. It includes a simple “shadow" macro that produces a shadow of any picture with an adjustable gray.I’m having lots of metafun!Gavin\startMPinclusions picture ball; ball := image( fill fullcircle scaled 1cm withshademethod "circular" withshadecenter (.25,.25) withshadecolors (.8white, black); draw fullcircle scaled 1cm withpen pencircle scaled 0.8pt ;); vardef shadow(expr p, t) = draw redecorated (draw p) withcolor t[background,0.8background]; enddef; \stopMPinclusions\startMPpage pair p; for i=0 upto 10: p := (i*cm/10, -((i-7.33)**2)*cm/7); shadow(ball shifted p, (i+1)/10) ; endfor draw ball shifted(1.1cm, -1.92cm) ;\stopMPpage___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://context.aanhet.net archive : https://bitbucket.org/phg/context-mirror/commits/ wiki : http://contextgarden.net ___
Re: [NTG-context] combination with lua
On 10/11/2021 1:38 PM, Adam Reviczky via ntg-context wrote:
Hi,
I am trying to use a combination figure with luacode (both with latest
MKIV and LMTX).
However, the figures do not line up in the grid of the combination.
I get the correct result with examples 1 and 2 below, but example 3
using lua functions for combination and externalfigure is what I wanted
to use in the first place.
MWE:
\starttext
\startluacode
-- Combination 1
context.startplacefigure({title = "Figure"})
context.startcombination({nx = "2", ny = "2"},
"\\externalfigure[cow][width=50mm]","Caption 1",
"\\externalfigure[cow][width=50mm]","Caption 2",
"\\externalfigure[cow][width=50mm]","Caption 3",
"\\externalfigure[cow][width=50mm]","Caption 4"
)
context.stopcombination()
context.stopplacefigure()
-- Combination 2
context.startplacefigure({title = "Figure"})
context.startcombination({nx = "2", ny = "2"},
"Picture 1","Caption 1",
"Picture 2","Caption 2",
"Picture 3","Caption 3",
"Picture 4","Caption 4"
)
context.stopcombination()
context.stopplacefigure()
-- Combination 3
context.startplacefigure({title = "Figure"})
context.startcombination({nx = "2", ny = "2"},
context.externalfigure({"cow"},{width = "50mm"}),"Caption 1",
context.externalfigure({"cow"},{width = "50mm"}),"Caption 2",
context.externalfigure({"cow"},{width = "50mm"}),"Caption 3",
context.externalfigure({"cow"},{width = "50mm"}),"Caption 4"
)
context.stopcombination()
context.stopplacefigure()
\stopluacode
\stoptext
Any hints on what I am doing wrong in example 3?
as in any prodedural language a function as argument gets immediately
executed so you need to delay:
context.startplacefigure({title = "Figure"})
context.startcombination({nx = "2", ny = "2"},
context.delayed.externalfigure({"cow"},{width = "50mm"}),
"Caption 1",
context.delayed.externalfigure({"cow"},{width = "50mm"}),
"Caption 2",
context.delayed.externalfigure({"cow"},{width = "50mm"}),
"Caption 3",
context.delayed.externalfigure({"cow"},{width = "50mm"}),
"Caption 4"
)
context.stopcombination()
context.stopplacefigure()
(this is why encoding complex documents completely in a scrtipt language
is non trivial and why for instance these template systems are there
because these accumulate)
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
-
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://context.aanhet.net
archive : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___
Re: [NTG-context] body text and footnote space
On 10/12/2021 3:09 AM, jbf via ntg-context wrote: Dear list, I note previous discussions on the matter of body text invading footnote space (as late as last year). As I am currently typesetting a 400 plus page academic text with hundreds of footnotes, and do not have the option of making them endnotes, I am facing this issue page after page. The only solution I have for now is to make per page layout adjustments to reduce a line or two, so there is a way to handle it, but given ConTeXt's 'perfection' generally, I would be very interested to know if there is any other solution forthcoming. I've tried various options in \setupfootnotes and \setuptolerance', but to no avail. Is this still the case in the latest version? 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 - ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://context.aanhet.net archive : https://bitbucket.org/phg/context-mirror/commits/ wiki : http://contextgarden.net ___
Re: [NTG-context] TeX's \downbracefill and \upbracefill
On 10/12/2021 7:47 AM, Rudolf Bahr via ntg-context wrote:
Hello to all,
in Knuth's "The TeXbook" page 225/226 (excerpt is appended here) braces
are to be seen which I'd need to typeset a genealogical table.
Now, the commands \downbracefill and \upbracefill are no context commands.
Please, are there correspondings to them?
$\overbrace{\hbox{}}$
\mathematics{\overbrace{\hbox{}}}
-
Hans Hagen | PRAGMA ADE
Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl
-
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://context.aanhet.net
archive : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___
Re: [NTG-context] Bloody PDF boxes and cr*p marks!
On 10/12/2021 12:36 PM, Henning Hraban Ramm via ntg-context wrote:
Comrades!
There must have been a time when PDF boxes (i.e. CropBox, TrimBox, BleedBox)
worked as they should, but it must have been a short time.
The wiki page https://wiki.contextgarden.net/PDF_Boxes is mostly a
documentation of bugs and workarounds, but even that is not entirely correct
(any more?).
I gave up on that subject and still fix the boxes with Acrobat Pro whenever I
need them to be correct. But that’s no solution.
(And it’s probably also my fault, since I was one of those who wanted this
implemented and then didn’t check enough if it does what it should.)
I long ago lost track of what all that means ... decades of pdf ...
different viewers, different interpretations ... validators complaining
about things missing ... i guess that bit (like annotations) will always
be in flux (also because specs came before implementations i guess).
Ok, calm down, try again...
* MediaBox is supposed to be the biggest, i.e. print sheet.
it is the oldest o fthe pack
* CropBox is the viewable area – usually same as MediaBox or TrimBox makes
sense.
needed, in order to make it possible to use a pdf as image
* BleedBox must be TrimBox plus bleed.
a relative new one, probably also sensitive for interpretation by
renderer, imo worthless
* ArtBox is neglectable for whole layouts (same as TrimBox might make sense),
just interesting in \externalfigure.
also worthless
According to PDF Standard, MediaBox is the only required one; but CropBox is
the most important one, since PDF viewers rely on it.
With
\setuppaper[A4]
all boxes can be the same (or undefined). Status quo.
With
\setuppaper[A4][A4,oversized]
I’d expect ConTeXt to set...
* MediaBox and CropBox to the bigger format
* TrimBox to the page format (A4)
* BleedBox also to the page format, while no bleed is defined
well, that's an assumption ... who knows what a printer (driver) does ...
Status quo: no additional boxes defined.
Beware, \showframe draws a green box at the paper size (supposed TrimBox), this is
misleading in Acrobat Reader & Pro, where the TrimBox is shown in green (if
this option is activated)!
Bleed is to be defined in \setuplayout:
\showframe
\setuppapersize[A4][A4,oversized]
\setuplayout[
location=middle,
bleedoffset=-5mm,
marking=on,
]
%\setupinteractionscreen[width=max,height=max]
\starttext
X
\stoptext
Status quo:
* works only with \setupinteractionscreen
* bleedoffset must be negative
* BleedBox is set, but not TrimBox (TB > BB is a nesting error)
Beware, \setupbleeding refers only to stretching of images (\externalfigure)!
fwiw, that bleeding options is mostly there to communicate with mp
This gives more or less correct results:
\setuplayout[
location=middle,
trimoffset=-7.5mm,
bleedoffset=3mm,
marking=on,
]
* still works only with \setupinteractionscreen
* negative trimoffset defines the TrimBox (actual page size), value is
subtracted from sheet size.
* positive bleedoffset (internally added to trimoffset)
* to define trimoffset, I must know the difference between paper size and sheet size
("oversized" adds 15 mm).
oversized is a convenience feature, in prepress one would define a real,
target size, not rely on a convenience value
I.e. ConTeXt “thinks” from the sheet size instead from the (IMO more natural)
paper size.
For me, the more natural setup would be:
\setuplayout[
trimoffset=0mm, % from the paper size outward
bleedoffset=3mm, % same, independent of trimoffset
]
% ... and no dependency on interactionscreen!
that's a historic fact ... special pdf features triggered by that
command .. basically tex only has a page size
So far, I ignored cropoffset.
The parameter in itself works as I expected it to: cropoffset=3mm decreases the
visible area by 3mm on each side.
But it also moves the other boxes by that value!
IMO that makes no sense, CropBox can be completely independent of the other
boxes!
It would be logical to use negative values here, since the size decreases, in
opposite to my suggested handling of the other parameters.
Yes, that would mean a backward incompatible change. But how many of us rely on
the strange current behavior?
Please let us fix this!
the problem is as usual documentation and indeed we can have some
backward compatibility issue here ... i honestly have no clue how
viewers and printers react (so if something would be added/changed it
would be option driven)
In some cases it makes sense to have different values on e.g. inner and outer
edges; I feat that would add a plethora of additional parameters
(leftbleedoffset, innerbleedoffset...).
Maybe give a list like in CSS? bleedoffset={3mm,3mm,3mm,0mm} – top, right,
bottom, left order implied; not very “ConTeXt style”.
probably spreads need some treatment (imposition)
(i'm pretty sure that changes will themselves introduce new issues)
anyway, we can look at it once we're all on lmtx because
[NTG-context] Bloody PDF boxes and cr*p marks!
Comrades!
There must have been a time when PDF boxes (i.e. CropBox, TrimBox, BleedBox)
worked as they should, but it must have been a short time.
The wiki page https://wiki.contextgarden.net/PDF_Boxes is mostly a
documentation of bugs and workarounds, but even that is not entirely correct
(any more?).
I gave up on that subject and still fix the boxes with Acrobat Pro whenever I
need them to be correct. But that’s no solution.
(And it’s probably also my fault, since I was one of those who wanted this
implemented and then didn’t check enough if it does what it should.)
Ok, calm down, try again...
* MediaBox is supposed to be the biggest, i.e. print sheet.
* CropBox is the viewable area – usually same as MediaBox or TrimBox makes
sense.
* BleedBox must be TrimBox plus bleed.
* ArtBox is neglectable for whole layouts (same as TrimBox might make sense),
just interesting in \externalfigure.
According to PDF Standard, MediaBox is the only required one; but CropBox is
the most important one, since PDF viewers rely on it.
With
\setuppaper[A4]
all boxes can be the same (or undefined). Status quo.
With
\setuppaper[A4][A4,oversized]
I’d expect ConTeXt to set...
* MediaBox and CropBox to the bigger format
* TrimBox to the page format (A4)
* BleedBox also to the page format, while no bleed is defined
Status quo: no additional boxes defined.
Beware, \showframe draws a green box at the paper size (supposed TrimBox), this
is misleading in Acrobat Reader & Pro, where the TrimBox is shown in green (if
this option is activated)!
Bleed is to be defined in \setuplayout:
\showframe
\setuppapersize[A4][A4,oversized]
\setuplayout[
location=middle,
bleedoffset=-5mm,
marking=on,
]
%\setupinteractionscreen[width=max,height=max]
\starttext
X
\stoptext
Status quo:
* works only with \setupinteractionscreen
* bleedoffset must be negative
* BleedBox is set, but not TrimBox (TB > BB is a nesting error)
Beware, \setupbleeding refers only to stretching of images (\externalfigure)!
This gives more or less correct results:
\setuplayout[
location=middle,
trimoffset=-7.5mm,
bleedoffset=3mm,
marking=on,
]
* still works only with \setupinteractionscreen
* negative trimoffset defines the TrimBox (actual page size), value is
subtracted from sheet size.
* positive bleedoffset (internally added to trimoffset)
* to define trimoffset, I must know the difference between paper size and sheet
size ("oversized" adds 15 mm).
I.e. ConTeXt “thinks” from the sheet size instead from the (IMO more natural)
paper size.
For me, the more natural setup would be:
\setuplayout[
trimoffset=0mm, % from the paper size outward
bleedoffset=3mm, % same, independent of trimoffset
]
% ... and no dependency on interactionscreen!
So far, I ignored cropoffset.
The parameter in itself works as I expected it to: cropoffset=3mm decreases the
visible area by 3mm on each side.
But it also moves the other boxes by that value!
IMO that makes no sense, CropBox can be completely independent of the other
boxes!
It would be logical to use negative values here, since the size decreases, in
opposite to my suggested handling of the other parameters.
Yes, that would mean a backward incompatible change. But how many of us rely on
the strange current behavior?
Please let us fix this!
In some cases it makes sense to have different values on e.g. inner and outer
edges; I feat that would add a plethora of additional parameters
(leftbleedoffset, innerbleedoffset...).
Maybe give a list like in CSS? bleedoffset={3mm,3mm,3mm,0mm} – top, right,
bottom, left order implied; not very “ConTeXt style”.
Hraban
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://context.aanhet.net
archive : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___
Re: [NTG-context] Clickable url problem with \useurl and \url
Hi,
> On 12 Oct 2021, at 04:30, Rik Kabel via ntg-context
> wrote:
>
> Hello List,
>
> I notice an inconsistency in the clickable area when using \useurl. With the
> following example, both the \from and the \url are clickable in some lines
> (as noted iin the value of \from) but in others, the \from is clickable but
> not the \url.
>
> It does seem sensitive to the urlL, but I cannot see a pattern.
It is the pdf viewer program that automatically interprets the \url-produced
text and 'invents' a link, it is not
ConTeXt itself. The exact rules may therefore vary depending on the pdf viewer
you use.
In Apple's Preview, all items are in fact clickable. But only \from produces
actual pdf hyperlink annotations.
> Should I use something other than \url[earlXX] here to get the clickable
> literal url from useurl?
This, maybe
\goto{\url[earlLH]}[url(earlLH)]
(perhaps wrapped in a short macro)
Best wishes,
Taco
—
Taco Hoekwater E: t...@bittext.nl
genderfluid (all pronouns)
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://context.aanhet.net
archive : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___
Re: [NTG-context] TLS Certificate Expired for the Wiki
> On 12 Oct 2021, at 08:41, Ramkumar KB via ntg-context > wrote: > > Hello, > > The TLS certificate for the Context wiki expired yesterday - valid only upto > 12-October-2021. I’ll fix that in a bit. > > Just an alert as Chrome now pops up the "Unsafe" alerts. > > Thank you, > > best regards, > Ramkumar > ___ > If your question is of interest to others as well, please add an entry to the > Wiki! > > maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context > webpage : http://www.pragma-ade.nl / http://context.aanhet.net > archive : https://bitbucket.org/phg/context-mirror/commits/ > wiki : http://contextgarden.net > ___ — Taco Hoekwater E: t...@bittext.nl genderfluid (all pronouns) ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://context.aanhet.net archive : https://bitbucket.org/phg/context-mirror/commits/ wiki : http://contextgarden.net ___
[NTG-context] TLS Certificate Expired for the Wiki
Hello, The TLS certificate for the Context wiki expired yesterday - valid only upto 12-October-2021. Just an alert as Chrome now pops up the "Unsafe" alerts. Thank you, best regards, Ramkumar ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://context.aanhet.net archive : https://bitbucket.org/phg/context-mirror/commits/ wiki : http://contextgarden.net ___
