[NTG-context] Re: context version 20240118 ("Registerhaltigkeit")
That's it! Many thanks to Hans, Hraban and especially Wolfgang for his
solution. This environment should become part of ConTeXt!
I have been a LaTeX/XeTeX/LuaLaTeX user for over 30 years and used it to
write my papers during my studies and use it for almost all my writing.
Now I wanted to try ConTeXt and will be glad if anyone can help me. As I
said, I am only a user.
Many thanks and best regards
Thomas
Am 22.01.24 um 20:24 schrieb Wolfgang Schuster:
Thomas Meyer schrieb am 22.01.2024 um 13:04:
Am 22.01.24 um 12:06 schrieb Henning Hraban Ramm:
Am 22.01.24 um 11:46 schrieb Thomas Meyer:
I might get a bit impatient if I have the impression that others
get an answer faster. Sorry for that.
It’s not unusual to get that impression. It depends on the current
attention, capacity and mood of the few who can answer your questions.
So the problem is still \hfill that the last paragraph is not on
grid in the new and the old version (and comma).
Grid is not as easy as it looks first. Low level tricks like fills
or skips can mess it up.
Maybe \startlinecorrection helps… (No, it doesn’t.)
It also doesn’t help to add a \blank or \par after \vfill.
I know it, i tried it. And I tried \snaptogrid \vbox {}, it doesn't
work too.
Only counting empty rows and set the number in \blank[ *big] works!
You need a fixed space (multiple of the line distance) between the
text blocks and \vfill is a variable space which isn't what you want
here.
TO get the desired space between the blocks you have to measure the
height of the text at the bottom and calculate the number of lines
which have to be added in the gap. Below is a simple solution which
adds the required number of \blank lines.
\def\PlaceAtBottom
{\par
\dowithnextbox
{\scratchdimen\dimexpr\pagegoal-\pagetotal\relax
\ifdim\nextboxht>\scratchdimen
\page
\getnoflines{\dimexpr\textheight-\nextboxht\relax}%
\dontleavehmode\blank[\number\numexpr\noflines-2\relax*line]%
\unvbox\nextbox
\else
\getnoflines{\dimexpr\scratchdimen-\nextboxht\relax}%
\blank[\number\numexpr\noflines-1\relax*line]%
\unvbox\nextbox
\fi}
\vbox}
\let\stopPlaceAtBottom\egroup
\def\startPlaceAtBottom
{\PlaceAtBottom\bgroup}
\mainlanguage[de]
\setupbodyfont[libertinus, 12pt]
\setuppagenumbering
[location={footer,middle}]
\setuplayout
[grid=yes]
\showgrid
\starttext
\samplefile{lorem}
\startPlaceAtBottom
{\sl\samplefile{lorem}}
\stopPlaceAtBottom
\page
\dorecurse{4}{\samplefile{lorem}}
\startPlaceAtBottom
{\sl\samplefile{lorem}}
\stopPlaceAtBottom
\stoptext
Wolfgang
___
If your question is of interest to others as well, please add an entry
to the Wiki!
maillist : ntg-context@ntg.nl /
https://mailman.ntg.nl/mailman3/lists/ntg-context.ntg.nl
webpage : https://www.pragma-ade.nl / https://context.aanhet.net
(mirror)
archive : https://github.com/contextgarden/context
wiki : https://wiki.contextgarden.net
___
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl /
https://mailman.ntg.nl/mailman3/lists/ntg-context.ntg.nl
webpage : https://www.pragma-ade.nl / https://context.aanhet.net (mirror)
archive : https://github.com/contextgarden/context
wiki : https://wiki.contextgarden.net
___
[NTG-context] Re: Why LuaMetaTex is so slow?
On Fri, 19 Jan 2024, Hans Hagen via ntg-context wrote:
> On 1/19/2024 12:34 AM, Aditya Mahajan wrote:
> > On Thu, 18 Jan 2024, Hans Hagen wrote:
> >
> >> Of course we'll never be as fast as (pure) plain tex (no layers added) or
> >> latex (which often is advocated as faster than context).
> >
> > I was curious, so did a quick experiment: typeset \input knuth 500 times.
> > Here are the results:
> >
> > pdflatex: 547 pages/sec
> > lualatex: 308 pages/sec
>
> opentype or type 1 ?
type 1. I did not change anything in the defaults. I'll try to figure out how
to load opentype fonts in latex, and test lualatex.
> > MKIV: 130 pages/sec
> > LMTX: 147 pages/sec
>
> that is weird as lmtx is always faster here (we loose some 15% on the backend
> compared to luatex, maybe even more, but we gain back quite a bit elsewhere
> for various reasons)
LMTX is faster for me as well.
> > Interestingly, pdflatex, lualatex, and MkIV all generated pdf with 1112
> > pages, while LMTX generated a pdf with 1250 pages. Both MkIV and LMTX take
> > the same time to run (8.5 sec) but LMTX generates more pages so it is
> > faster.
>
> puzzling
>
> > Of course, this is a meaningless experiment from a practical point of view
> > as a 1000 page document will be more complex than just text.
> % engine=pdftex 1.2
> % engine=luatmetatex 1.6
> % engine=luatex 1.8
> % engine=xetex 2.4
>
> \starttext
>
> \dorecurse{500} {
> \input knuth \par
> }
>
> \stoptext
>
> 125 pages, so how does your test file look
5000 recursions (not 500, sorry about that).
\starttext
\dorecurse{5000}{\ReadFile{knuth}}
\stoptext
I'll send you the PDFs offlist.
Aditya
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl /
https://mailman.ntg.nl/mailman3/lists/ntg-context.ntg.nl
webpage : https://www.pragma-ade.nl / https://context.aanhet.net (mirror)
archive : https://github.com/contextgarden/context
wiki : https://wiki.contextgarden.net
___
[NTG-context] Re: Why LuaMetaTex is so slow?
On 1/19/2024 12:34 AM, Aditya Mahajan wrote:
On Thu, 18 Jan 2024, Hans Hagen wrote:
Of course we'll never be as fast as (pure) plain tex (no layers added) or
latex (which often is advocated as faster than context).
I was curious, so did a quick experiment: typeset \input knuth 500 times. Here
are the results:
pdflatex: 547 pages/sec
lualatex: 308 pages/sec
opentype or type 1 ?
MKIV: 130 pages/sec
LMTX: 147 pages/sec
that is weird as lmtx is always faster here (we loose some 15% on the
backend compared to luatex, maybe even more, but we gain back quite a
bit elsewhere for various reasons)
Interestingly, pdflatex, lualatex, and MkIV all generated pdf with 1112 pages,
while LMTX generated a pdf with 1250 pages. Both MkIV and LMTX take the same
time to run (8.5 sec) but LMTX generates more pages so it is faster.
puzzling
Of course, this is a meaningless experiment from a practical point of view as a
1000 page document will be more complex than just text.
% engine=pdftex 1.2
% engine=luatmetatex 1.6
% engine=luatex 1.8
% engine=xetex 2.4
\starttext
\dorecurse{500} {
\input knuth \par
}
\stoptext
125 pages, so how does your test file look
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 /
https://mailman.ntg.nl/mailman3/lists/ntg-context.ntg.nl
webpage : https://www.pragma-ade.nl / https://context.aanhet.net (mirror)
archive : https://github.com/contextgarden/context
wiki : https://wiki.contextgarden.net
___
[NTG-context] Re: Toggling the symbol for the zero-width joiner and related Unicode control characters
-- Original Message -- From "Hans Hagen via ntg-context" mailto:ntg-context@ntg.nl>> To "ntg-context@ntg.nl<mailto:ntg-context@ntg.nl>" mailto:ntg-context@ntg.nl>> Cc "Hans Hagen" mailto:j.ha...@freedom.nl>> Date 9/22/2023 10:44:38 AM Subject [NTG-context] Re: Toggling the symbol for the zero-width joiner and related Unicode control characters (It seems he never considered making it an opentype feature in the font itself, but since his focus is/was XeTeX/HB (HB is rather rigid and dictatorial) I guess that's not surprising.) I admit that I don't follow what happens with xetex (they changed the rendere at some point indeed) not HB (I only notice that it gets updates frequently in the tex live repository which makes me wonder how one retains compatility unless one freezes). I actually kept the lib binding code that can use it around for your font testing (we wanted to see what uniscribe does), not sure if it still works. I remember the experimental uniscribe binding, don't recall that it was ever officially released. (Did Kai Bormann ever work with it?). I hope that it still works or can be resurrected when the time comes for testing -) Anyway, we're entering the bug cq. side effect becomes feature area here; just like yesterdays perfect bidi algorithm is todays less pefect one replaced by ... But therein lies the problem: ConTeXt shows the rendering by default, and we need to turn it off. Since most non-Latin typography targets Uniscribe applications which allows for toggling, the font developers (commercial or free) don't have to concern themselves with this issue. if context shows it then it is not a feature but hard coded shapes which is weird; how does one know what to 'remove' or not? And in what stage? If they are zero width it is simple to ignore them in the backend, if they have dimensions (w/h/d) then they contributed and wiping is tricky The metrics should be dimensionless and most Arabic fonts do that, but Lotus Linotype gives them width (one wonders why). Perhaps the Lotus designers thought that giving them width makes them easier to edit, which is indeed the case. And perhaps they were satisfied that Word/InDesign would be able, as needed, to toggle the metrics on and off as well as the shape. That WYSIWYG-DTP curse again.. \setcharacterstripping[1] gives the right results with Lotus (at least so far) -- see attached. Was pleasantly surprised that the spurious width was also suppressed. \setcharacterstripping[0] toggles back -- another pleasant result -) Since Word rules the world, most font designers target it. Since Word provides for toggling the symbols -- needed for editing purposes -- there was no need for Arabic-script font designers to worry about the symbols showing up where they are not wanted. (I suppose that InDesign behaves the same way.) I don't know ... irr these dtp programs are more like "if you want this feature applied select a range of characters and apply it" That's what was meant when I spoke of the continued effects of the WYSIWYG curse: It saved font designers from having to think much about this issue. In some way it's also flaws in the open type approach. Basically that happens when application stuff becomes a standard and one forgets that it was (is) application driven. (And you haven't seen variable fonts and color fonts yet ... no pretty standards either.) I'm in the process of switching from Multiple Masters sources to variable, so will surely encounter it soon. Unfortunately there is indeed a frustrating gray area in this arena between knowing where the standards end and where the diktats of corporations (or even free-software consortiums like HB) begin, as we've discussed in the past. With variable fonts, one has to add some degree of arbitrariness.. Not really -) This brings us to the point of consistency: For Arabic-script fonts, hard symbolic rendering of the Unicode control characters is the rule, not the exception. So not "an inconsistent mess" -- at least not as far as Arabic-script typography is concerned. Funny rules ... but I'm not going top enable 'wipe' by default: after all, one gets what one deserves, nto what one likes (which can differ per day). But you can enable the wiping. We can of course ignore in the backend when zero width but then how to explain that they contributed to the ht/dp (unless we wipe these dimensions) ... all slow-downers So far \setcharacterstripping[1] is giving the right results. If the relevant trackers are available, could add them to the attached test. But presumably you know how and why it works even for a non-dimensionless glyph. so you want to see soem zwj sumbol in a rendered text? Only in verbatim/\type'd text where it is appropriate, even necessary. Thanks to Word/WYSIWYG, the rule is de facto, but it is not de jure -) Ideally, Scintilla (Scite, Notepad++, etc.) should do the same
[NTG-context] Re: Toggling the symbol for the zero-width joiner and related Unicode control characters
On 9/22/2023 3:51 PM, Hamid,Idris wrote: -- Original Message -- From "Hans Hagen" mailto:j.ha...@xs4all.nl>> To "ntg-context@ntg.nl<mailto:ntg-context@ntg.nl>" mailto:ntg-context@ntg.nl>> Date 9/22/2023 7:15:25 AM Subject [NTG-context] Re: Toggling the symbol for the zero-width joiner and related Unicode control characters ** Caution: EXTERNAL Sender ** On 9/22/2023 2:39 PM, Hamid,Idris wrote: b. we want all Unicode control symbols to be suppressed in final pdf output (for, e.g., printing). they basically are unless some font features keeps them around which is out of our control irr it was you who wanted them to be wiped decades ago as some fonts visualized them by default Yes, that's exactly the point: Somewhere along the course of history, it became standard for Arabic-script fonts (and other cursive-script fonts as well) to include symbols for the control characters. In typo-rep there is also %D \starttyping %D \definefontfeature[default][default][mode=node,formatters=strip] %D \stoptyping You included some notes about Khaled, so I guess he faced the same issue. His Amiri font displays the symbols by default, as do other Arabic fonts. (It seems he never considered making it an opentype feature in the font itself, but since his focus is/was XeTeX/HB (HB is rather rigid and dictatorial) I guess that's not surprising.) I admit that I don't follow what happens with xetex (they changed the rendere at some point indeed) not HB (I only notice that it gets updates frequently in the tex live repository which makes me wonder how one retains compatility unless one freezes). I actually kept the lib binding code that can use it around for your font testing (we wanted to see what uniscribe does), not sure if it still works. Anyway, we're entering the bug cq. side effect becomes feature area here; just like yesterdays perfect bidi algorithm is todays less pefect one replaced by ... But therein lies the problem: ConTeXt shows the rendering by default, and we need to turn it off. Since most non-Latin typography targets Uniscribe applications which allows for toggling, the font developers (commercial or free) don't have to concern themselves with this issue. if context shows it then it is not a feature but hard coded shapes which is weird; how does one know what to 'remove' or not? And in what stage? If they are zero width it is simple to ignore them in the backend, if they have dimensions (w/h/d) then they contributed and wiping is tricky Since Word rules the world, most font designers target it. Since Word provides for toggling the symbols -- needed for editing purposes -- there was no need for Arabic-script font designers to worry about the symbols showing up where they are not wanted. (I suppose that InDesign behaves the same way.) I don't know ... irr these dtp programs are more like "if you want this feature applied select a range of characters and apply it" That's what was meant when I spoke of the continued effects of the WYSIWYG curse: It saved font designers from having to think much about this issue. In some way it's also flaws in the open type approach. Basically that happens when application stuff becomes a standard and one forgets that it was (is) application driven. (And you haven't seen variable fonts and color fonts yet ... no pretty standards either.) Not really -) This brings us to the point of consistency: For Arabic-script fonts, hard symbolic rendering of the Unicode control characters is the rule, not the exception. So not "an inconsistent mess" -- at least not as far as Arabic-script typography is concerned. Funny rules ... but I'm not going top enable 'wipe' by default: after all, one gets what one deserves, nto what one likes (which can differ per day). But you can enable the wiping. We can of course ignore in the backend when zero width but then how to explain that they contributed to the ht/dp (unless we wipe these dimensions) ... all slow-downers so you want to see soem zwj sumbol in a rendered text? Only in verbatim/\type'd text where it is appropriate, even necessary. Thanks to Word/WYSIWYG, the rule is de facto, but it is not de jure -) Ideally, Scintilla (Scite, Notepad++, etc.) should do the same, or provide a toggle, as MS Notepad does. (Tangent: In terms of Unicode functionality, MS Notepad is still unrivalled, even in 2023!) We agree that for final printed output it is not appropriate (except perhaps in a paper that discusses Unicode, fonts, etc., in which case it can be rendered using the figures or symbols mechanism -- or toggled as needed.) so what is it now: - for verbatim you can use almfixed and they show up (when they have a glyph) - for other fonts if they have them they show up (unless gone in the process ot rendering) - but you
[NTG-context] Re: Toggling the symbol for the zero-width joiner and related Unicode control characters
-- Original Message -- From "Hans Hagen" mailto:j.ha...@xs4all.nl>> To "ntg-context@ntg.nl<mailto:ntg-context@ntg.nl>" mailto:ntg-context@ntg.nl>> Date 9/22/2023 7:15:25 AM Subject [NTG-context] Re: Toggling the symbol for the zero-width joiner and related Unicode control characters ** Caution: EXTERNAL Sender ** On 9/22/2023 2:39 PM, Hamid,Idris wrote: b. we want all Unicode control symbols to be suppressed in final pdf output (for, e.g., printing). they basically are unless some font features keeps them around which is out of our control irr it was you who wanted them to be wiped decades ago as some fonts visualized them by default Yes, that's exactly the point: Somewhere along the course of history, it became standard for Arabic-script fonts (and other cursive-script fonts as well) to include symbols for the control characters. In typo-rep there is also %D \starttyping %D \definefontfeature[default][default][mode=node,formatters=strip] %D \stoptyping You included some notes about Khaled, so I guess he faced the same issue. His Amiri font displays the symbols by default, as do other Arabic fonts. (It seems he never considered making it an opentype feature in the font itself, but since his focus is/was XeTeX/HB (HB is rather rigid and dictatorial) I guess that's not surprising.) But therein lies the problem: ConTeXt shows the rendering by default, and we need to turn it off. Since most non-Latin typography targets Uniscribe applications which allows for toggling, the font developers (commercial or free) don't have to concern themselves with this issue. ? Since Word rules the world, most font designers target it. Since Word provides for toggling the symbols -- needed for editing purposes -- there was no need for Arabic-script font designers to worry about the symbols showing up where they are not wanted. (I suppose that InDesign behaves the same way.) That's what was meant when I spoke of the continued effects of the WYSIWYG curse: It saved font designers from having to think much about this issue. Not really -) This brings us to the point of consistency: For Arabic-script fonts, hard symbolic rendering of the Unicode control characters is the rule, not the exception. So not "an inconsistent mess" -- at least not as far as Arabic-script typography is concerned. so you want to see soem zwj sumbol in a rendered text? Only in verbatim/\type'd text where it is appropriate, even necessary. Thanks to Word/WYSIWYG, the rule is de facto, but it is not de jure -) Ideally, Scintilla (Scite, Notepad++, etc.) should do the same, or provide a toggle, as MS Notepad does. (Tangent: In terms of Unicode functionality, MS Notepad is still unrivalled, even in 2023!) We agree that for final printed output it is not appropriate (except perhaps in a paper that discusses Unicode, fonts, etc., in which case it can be rendered using the figures or symbols mechanism -- or toggled as needed.) I hope the above made sense. Best wishes -- Idris Samawi Hamid, Professor Department of Philosophy Colorado State University Fort Collins, CO 80523 ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / https://www.ntg.nl/mailman/listinfo/ntg-context webpage : https://www.pragma-ade.nl / http://context.aanhet.net archive : https://bitbucket.org/phg/context-mirror/commits/ wiki : https://contextgarden.net ___
Re: [NTG-context] Off topic: Does a 'free for commercial use' flared-sans font exist in the world?
On 6/18/2023 8:37 PM, Carlos via ntg-context wrote: On Sat, Jun 17, 2023 at 06:53:06PM +0200, Hans Hagen via ntg-context wrote: On 6/17/2023 2:06 AM, linguafalsa--- via ntg-context wrote: On Fri, Jun 16, 2023 at 06:35:49PM +0200, Gerben Wierda via ntg-context wrote: I know this is off topic, but I suspect this community is actually one of the best places to find an answer. It is the best community. And I tell you what. What happened is that all TeX engines have neglected fonts from the beginning. Really? When tex showed up digital font technology was pretty much in flux. And, with metafont being part of the tex ecosystem, one can argue that tex was quite innovative too. Ecosystem. I would be very careful by including an ecosystem there. Yes. Yes. The TeX ecosystem is obviously part of TeX but is not part of the ecosystem of fonts either. And what is done on ecosystems can either benefit or affect ecosystems greatly. And it's a known trait that humans have been known for having more of a flock group mentality for no apparent rationally-based reasons than just being themselves making these decisions/following instincts or whatever and not because of a particular ecosystem, or for the benefit of the latter. With ecosystemn I mean: tex, metafont, cmr fonts, all kind of tools ... evolving into more engines, more fonts, macro packages, distributions, user groups and use group journals, meetings etc And the above does not imply, bear with me here, that metafont was not innovative, but it can be argued that without TeX there is no metafont, so no room is left for errors either. So, yes, it must be innovative. It has to be. There had to be metafont because there was not much else that could provide what tex needed (at that time). Potscript and its fonts came aroudn at the same time and were rather closed technologies. But as soon possible backend drivers (also part of the tex ecosystem) kicked in. Then we got virtual fonts which enhanced tex's capabilities. I really like Optima, and what I really like about it is the 'flared style'. But I would like to move to a flared-sans font that gives me more licensing freedom. I haven't been able to find one after extensive searching. The only one who were reasonably priced (not free) were the URW Classico ones in Adobe Creative Cloud, but those can only be used in Adobe programs like InDesign (and not TeX). Licensing freedom is an oxymoron. There's no freedom in licensing. Only greed. The only extension engine that at one point had a plan in mind, or most of the bases covered in this regard was Omega. One needs morr than plans. Afaik omega was more about input processing and th efont part was mostly going beyond 8 bit fonts but i might have missed something (omega was never productin ready). Notwithstanding the intricacies/details of what may have actually happened with its short lifespan I think it's more than clear the lack of support behind it. I'm not going to delve into what exactly caused its demise or if it was simply the after effect of other projects that contributed to it. It's irrelevant. Hm, its time span was not that short ... I first heard of omega at the eurotex meeting in arnhem where also etex was discussed (and you dont'want me to cite things said there) .. in successive years there have been announcemnts etc. However, for an engine to be used it must work reliable and guiseppes 'aleph' was basically a variant of omega that also had etex on board. In fact, that was supported in context mkii (and some used it because of the input processor which i think was the more innovative thing in omega but i never dived into it, other users did) It makes no sense to discuss into all this as all teams involved in engines have published in user group journals or presented plans at meetings. Also keep in mind that we're talking frontend here; omega is dvi based so like regular tex and etex whatever it does with fonts is not really related to the engine bu tup to the backend: the engine only needs metrics (omega extended tfm into ofm for that). pdftex brought a pdf backend, xetex pipes into a dvi backend, luatex has a pdf backend built in; (nts being related to etec never took of also because it was not that useable and in the meantime pdftex had taken over); there are afaik some very useable japanese tex engines; the fact that dvi survived was due to dvipdfmx development But stand by for a second. I look forward to your quick witted answers. But hear me out Suppose that on my prior message I was referring indeed to 'mkii' and not to 'omega' And also suppose for a second that the term 'omega' is to be replaced with 'mkii' on your reply accordingly After careful observation the resemblance is quite possibly identical, isn't it? and it could also inarguably apply to the circumstances as well. Don't you think? no it isn't, its building upon hat is there: mkii -> mkiv -> mkxl (p
Re: [NTG-context] Off topic: Does a 'free for commercial use' flared-sans font exist in the world?
On Sat, Jun 17, 2023 at 06:53:06PM +0200, Hans Hagen via ntg-context wrote: > On 6/17/2023 2:06 AM, linguafalsa--- via ntg-context wrote: > > On Fri, Jun 16, 2023 at 06:35:49PM +0200, Gerben Wierda via ntg-context > > wrote: > > > I know this is off topic, but I suspect this community is actually one of > > > the best places to find an answer. > > > > > > > It is the best community. And I tell you what. > > > > What happened is that all TeX engines have neglected fonts from the > > beginning. > > Really? When tex showed up digital font technology was pretty much in flux. > And, with metafont being part of the tex ecosystem, one can argue that tex > was quite innovative too. Ecosystem. I would be very careful by including an ecosystem there. Yes. Yes. The TeX ecosystem is obviously part of TeX but is not part of the ecosystem of fonts either. And what is done on ecosystems can either benefit or affect ecosystems greatly. And it's a known trait that humans have been known for having more of a flock group mentality for no apparent rationally-based reasons than just being themselves making these decisions/following instincts or whatever and not because of a particular ecosystem, or for the benefit of the latter. And the above does not imply, bear with me here, that metafont was not innovative, but it can be argued that without TeX there is no metafont, so no room is left for errors either. So, yes, it must be innovative. It has to be. > > Potscript and its fonts came aroudn at the same time and were rather closed > technologies. But as soon possible backend drivers (also part of the tex > ecosystem) kicked in. > > Then we got virtual fonts which enhanced tex's capabilities. > > > > I really like Optima, and what I really like about it is the 'flared > > > style'. > > > > > > But I would like to move to a flared-sans font that gives me more > > > licensing freedom. I haven't been able to find one after extensive > > > searching. The only one who were reasonably priced (not free) were the > > > URW Classico ones in Adobe Creative Cloud, but those can only be used in > > > Adobe programs like InDesign (and not TeX). > > > > > > > Licensing freedom is an oxymoron. There's no freedom in licensing. > > Only greed. > > > > The only extension engine that at one point had a plan in mind, > > or most of the bases covered in this regard was Omega. > > One needs morr than plans. Afaik omega was more about input processing and > th efont part was mostly going beyond 8 bit fonts but i might have missed > something (omega was never productin ready). Notwithstanding the intricacies/details of what may have actually happened with its short lifespan I think it's more than clear the lack of support behind it. I'm not going to delve into what exactly caused its demise or if it was simply the after effect of other projects that contributed to it. It's irrelevant. But stand by for a second. I look forward to your quick witted answers. But hear me out Suppose that on my prior message I was referring indeed to 'mkii' and not to 'omega' And also suppose for a second that the term 'omega' is to be replaced with 'mkii' on your reply accordingly After careful observation the resemblance is quite possibly identical, isn't it? and it could also inarguably apply to the circumstances as well. Don't you think? I mean, it's like comparing oranges with apples, and mkii with mkiv and mkvi and so forth If you were to tell me then, that mkii for instance was not aimed as an input processing I can almos assure its falsiliability is written all over, even before the sentence is processed and thought out loud by you. Bottom line is that the production-ready part is an obvious byproduct of its short lifespan, but one cannot be making the claim (false as would have been seen later, because omega carbon footprint lasted more on books than on shelves really, not for selling out fast but rather discontinued quickly) and that its goal was solely within this input processing spectrum. Because it wasn't. Or heck or heck. Let's go even further. By making the dubious assertion that we've been built with noses to hold our eyeglasses lest these eyeglasses fall off while reading, or that we've been built with ears to hold pencils and pens in the ears while thinking and writing. For crying out loud. > > It is xetex that hooked into opentype although pdftex can actually deal with > truetype fonts to some extend. Before there was something 'opentype' we had > two competing but similar technologies. And it took a while before it was > even clear how to interpre the specification (also think about reverse > engeneering fonts and heuristics and ... bugs or features ...).
Re: [NTG-context] Off topic: Does a 'free for commercial use' flared-sans font exist in the world?
On 6/17/2023 2:06 AM, linguafalsa--- via ntg-context wrote: On Fri, Jun 16, 2023 at 06:35:49PM +0200, Gerben Wierda via ntg-context wrote: I know this is off topic, but I suspect this community is actually one of the best places to find an answer. It is the best community. And I tell you what. What happened is that all TeX engines have neglected fonts from the beginning. Really? When tex showed up digital font technology was pretty much in flux. And, with metafont being part of the tex ecosystem, one can argue that tex was quite innovative too. Potscript and its fonts came aroudn at the same time and were rather closed technologies. But as soon possible backend drivers (also part of the tex ecosystem) kicked in. Then we got virtual fonts which enhanced tex's capabilities. I really like Optima, and what I really like about it is the 'flared style'. But I would like to move to a flared-sans font that gives me more licensing freedom. I haven't been able to find one after extensive searching. The only one who were reasonably priced (not free) were the URW Classico ones in Adobe Creative Cloud, but those can only be used in Adobe programs like InDesign (and not TeX). Licensing freedom is an oxymoron. There's no freedom in licensing. Only greed. The only extension engine that at one point had a plan in mind, or most of the bases covered in this regard was Omega. One needs morr than plans. Afaik omega was more about input processing and th efont part was mostly going beyond 8 bit fonts but i might have missed something (omega was never productin ready). It is xetex that hooked into opentype although pdftex can actually deal with truetype fonts to some extend. Before there was something 'opentype' we had two competing but similar technologies. And it took a while before it was even clear how to interpre the specification (also think about reverse engeneering fonts and heuristics and ... bugs or features ...). TeX was always pretty fast in picking up new stuff (maybe users less so). When it came to commercial fonts the plan of action ahead was by including PFC data on these very same commercial fonts that would benefit primarily its opentype versions in the long run. What is PFC data? What do you have right now? Opentype fonts only. Sure. Quality can be even the same than its type1 counterpart, and at times not so much according so some folks that have bothered to go the extra length in making the most accurate comparison that's available between them two. For most fonts it's just 'more shapes' which then also leads to more ligatures, kerns etc btu that is already nice. And when fonts lack something we can always tweak them (runtime). But looking at it from a bright side/perspective, I think we're no longer facing the same pre-historic constraints of including a font as before, as long as it's not for commercial purposes, You are well aware of these non and commercial uses even before your extensive search anyway, I'm not sure what is the difference between commercial fonts and free ones as they use the same technology; with some exceptions, fonts are not that expensive (take lucida from tug, making fonts takes time after all); and for publishers it's noise on their budgets. p.s many many years ago I read and followed some publications about the aformentioned extension and just went over them recently, to have an idea what did and did not work. In regards to typefaces, its goal was unmatched, or so I think. It might be comforting to know that right from the start luatex made a lot possible wrt fonts (runtime manipulation) and was also one of the first to support variable fonts, color fonts etc (not that many care about that). And with luametatex we go even further. I found some flared-sans fonts, but not one with at least regular, italic, bold, and bold-italic. Is there really not a single flared-sans font that is really free (so also for commercial use) to use out there? I had to search the net to figure out that flare sans fonts are sans fonts with serifs For those into fonts: https://tug.org/TUGboat/tb44-1/tb136carter-romano.pdf I a very nice overview of how it went with digital fonts (and what we probably lost in getting where we are now and might loose soon). 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 / https://www.ntg.nl/mailman/listinfo/ntg-context webpage : https://www.pragma-ade.nl / http://context.aanhet.net archive : https
Re: [NTG-context] Workshop at FrOSCon
Am 09.07.22 um 19:27 schrieb Henning Hraban Ramm via ntg-context: Am 09.07.22 um 17:48 schrieb juh+ntg-context--- via ntg-context: My workshop was accepted. What shall I cover? It's a workshop for beginners? - Installation - Hello word What would you cover? Project structure? Style creation? In my experience, most participants will know LaTeX, i.e. you must tell them to forget everything they believe to know about TeX ;P Oh, and don’t tell them that ConTeXt LMTX is much, much faster than any LaTeX, because that’s a secret ;) (On the German list TeX-D-L some are discussing if LuaTeX is better than pdfTeX/XeTeX, and some are complaining that LuaLaTeX is too slow, of course...) HR ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / https://www.ntg.nl/mailman/listinfo/ntg-context webpage : https://www.pragma-ade.nl / http://context.aanhet.net archive : https://bitbucket.org/phg/context-mirror/commits/ wiki : https://contextgarden.net ___
Re: [NTG-context] Transliteration
On 2/3/2022 10:01 PM, Mojca Miklavec wrote:
On Thu, 3 Feb 2022 at 21:41, Hans Hagen wrote:
I have also merged the Serbian hyphenation patterns, so there is no need
to switch the language in order to have hyphenation in transliterated text.
That was possible because cyrillic and latin scripts use different code
points, and there are no conflicts in patterns.
So I suggest merging the patterns for Serbian cyrillic and latin.
I'd like to hear Arthur / Mojca on that we can of course load them
both but if that is an upstream merge i'll wait for that
Yes, loading both patterns at once is definitely the correct approach.
That's what the rest of the TeX world already does (at least LuaTeX
and XeTeX; pdfTeX not of course), see
https://github.com/hyphenation/tex-hyphen/blob/master/hyph-utf8/tex/generic/hyph-utf8/loadhyph/loadhyph-sr-latn.tex
We have two sets of Cyrillic patterns (and several Latin ones as
well), so composing a single file was a bit of a (somewhat political)
challenge.
Now at least in theory the users are free to choose which of the two
sets of patterns they want.
I never checked what ConTeXt was doing with the Serbian patterns.
Personally I would suggest taking hyph-sh-cyrl.pat.txt and hyph-sh-latn.pat.txt.
we currently do this:
{ "sr", "hyph-sr","serbian", false, { "hyph-sr-cyrl",
"hyph-sr-latn" }, },
so you suggest to replace that by the "sh" variants
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] Transliteration
On Thu, 3 Feb 2022 at 21:41, Hans Hagen wrote: > > > I have also merged the Serbian hyphenation patterns, so there is no need > > to switch the language in order to have hyphenation in transliterated text. > > That was possible because cyrillic and latin scripts use different code > > points, and there are no conflicts in patterns. > > So I suggest merging the patterns for Serbian cyrillic and latin. > > I'd like to hear Arthur / Mojca on that we can of course load them > both but if that is an upstream merge i'll wait for that Yes, loading both patterns at once is definitely the correct approach. That's what the rest of the TeX world already does (at least LuaTeX and XeTeX; pdfTeX not of course), see https://github.com/hyphenation/tex-hyphen/blob/master/hyph-utf8/tex/generic/hyph-utf8/loadhyph/loadhyph-sr-latn.tex We have two sets of Cyrillic patterns (and several Latin ones as well), so composing a single file was a bit of a (somewhat political) challenge. Now at least in theory the users are free to choose which of the two sets of patterns they want. I never checked what ConTeXt was doing with the Serbian patterns. Personally I would suggest taking hyph-sh-cyrl.pat.txt and hyph-sh-latn.pat.txt. Mojca ___ 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] new upload
On Sunday, January 23, 2022 1:28:52 PM IST hanneder--- via ntg-context wrote:
> When using these fonts regularly, one notices very erratic formatting
> phenomena that must have to
> do with the Devanagarī font, or its interaction with (Xe)TeX. Perhaps
> this is the same phenomenon
> seen from the user side.
>
> In my case things improved when I switched to Adishila (in XeTeX):
>
> \newfontfamily\sanskritfont[Script=Devanagari,Mapping=RomDev,Scale=1.45]{Adi
> shilaSan}
>
> This is, to my taste, the nicest Sanskrit font, but it is difficult to
> decide between Adishila and
> Shobhika.
Adishila is a great font too and comes in many more styles (letter press, etc)
than Shobhika. However the latter has more conjuncts. For example:
ङ्क्ल
ङ्ग्ध्व
appear as halant forms in Adishila while they are proper conjuncts in
Shobhika. Of course, these are rare conjuncts, so …
Anyway, in ConTeXt Adishila works well with
features=devanagari-one
> I cannot say how thrilled I am about the Indic support, thanks a lot
> to Kaushika!
It is very much an ongoing effort. I am working on some proper documentation
soon to serve as a guide for fonts (what works, what doesn't, fixes, hacks,
etc). But mostly it is in a very usable state (for the most part).
I am very much a non-expert and helping in very little ways. It is Hans in the
background who is doing all the really important things with the code, design
and engineering of the system. So really, we should thank him!
kauśika
___
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] new upload
(it is a bit of a pity that support for indic scripts is such a
weird mix of font technology and
engine dependent reshuffling ... probably also driven by limitations
of open type at that time)>
When using these fonts regularly, one notices very erratic formatting
phenomena that must have to
do with the Devanagarī font, or its interaction with (Xe)TeX. Perhaps
this is the same phenomenon
seen from the user side.
In my case things improved when I switched to Adishila (in XeTeX):
\newfontfamily\sanskritfont[Script=Devanagari,Mapping=RomDev,Scale=1.45]{AdishilaSan}
This is, to my taste, the nicest Sanskrit font, but it is difficult to
decide between Adishila and
Shobhika.
The Murty font is also quite good, but it is commercial and cannot be
used for book production. I
asked whether there was a way to get a licence, but at the time this
was impossible. But the font
team there recommended ``Sanskrit Text'' (Sansk.ttf) which is one of
their products that made it
into a Microsoft Windows Standard font (I am not using Windows). It is
also very good, but Adishila
works better for me.
I cannot say how thrilled I am about the Indic support, thanks a lot
to Kaushika!
Best
Jürgen
- Nachricht von kauśika via ntg-context -
Datum: Sat, 22 Jan 2022 16:08:10 +0530
Von: kauśika via ntg-context
Antwort an: mailing list for ConTeXt users
Betreff: Re: [NTG-context] new upload
An: mailing list for ConTeXt users
Cc: kauśika
On Saturday, January 22, 2022 3:55:12 PM IST Hans Hagen via
ntg-context wrote:
Is there a font out there that supports all these scripts in one font?
Shobhika font is a free font that has some of the largest number of glyphs
(i.e has many conjuncts) for the Devanagari script.
https://github.com/Sandhi-IITBombay/Shobhika
The font also has a good Latin component based on PT Serif. This Latin part
has good support for the roman (IAST) transliteration for Sanskrit. But
strictly only the IAST spec character for Sanskrit are available.
It also has glyphs for some commonly used mathematical symbols.
Noto Serif Devanagari is also decent for just Devanagari (not sure
of the IAST
part).
As for Sans typefaces, Mukta Devanagari is a free font:
https://github.com/EkType/Mukta
Of these, Shobhika has the best conjunct coverage. I will shortly update the
wiki with a much more exhaustive list and report here.
kauśika
___
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
___
- Ende der Nachricht von kauśika via ntg-context
-
---
Prof. Dr. Juergen Hanneder
Philipps-Universitaet Marburg
FG Indologie u. Tibetologie
Deutschhausstr.12
35032 Marburg
Germany
Tel. 0049-6421-28-24930
hanne...@staff.uni-marburg.de
___
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] Critical Editions?
Thank you very much Arthur ! Yves Codet (Assistant Professor at Toulouse University, member of CRAPA an institutional public research in Humanities in South of France) is involved in TeX patterns for Greek and Indic languages. He is a translator of Indian theater pieces (among other things). See there : https://ctan.org/tex-archive/macros/xetex/hyphenation/sanhyph And his involvement in the discussion about Devanagari romanisation for translitteration and/or specific UTF8 specification in order to respect Devanagari and Brahmi hyphenation with XeTeX. https://tug.org/pipermail/xetex/2008-October/010904.html Le 10/01/2022 à 12:26, Arthur Rosendahl via ntg-context a écrit : On Sun, Jan 09, 2022 at 11:46:44PM +0100, Hans Hagen via ntg-context wrote: On 1/9/2022 11:23 AM, hanneder--- via ntg-context wrote: 1. In Sanskrit prose it is possible to produce compounds that span a few lines. The concept of "word" or "word division" fails here, as are the TeX mechanisms. What we need in practice would be a "hyphenation" for the language Sanskrit that hyphenates after all Sanskrit vowels (in transcription this would be a, ā, i, ī, u, ū, ṛ, ḷ, e, o, ai, au. The last two cannot be split, "au" is one vowel with one vowel sign in the original script). Of course, we want to improve this automatic spelling occasionally, so we need to be able to insert a \- without thereby disabling the hyphenation for this compound. I think in critical editions the problem of the disabled hyphenation also arises when a variant is added inside a word. In any case hyphenation is a real nuisance in critical editions. hypenation ... so no patterns, just injecting discretionaries after specific vowels ... doable but it has to happen a some specific moment because when language bound it's too soon, and the font handler does some reshuffling; it can probabloy best be done after fonts have been done ... given specs a typical rainy weekend activity There are patterns, that implement almost exactly the kind of automatic hyphenation Jürgen describes (see https://github.com/hyphenation/tex-hyphen/blob/master/hyph-utf8/tex/generic/hyph-utf8/patterns/tex/hyph-sa.tex#L50L134). They’re just not in the ConTeXt distribution ... Arthur ___ 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 ___ -- Jean-Pierre Delange Ancients Professeur Agrégé de Philosophie (HC) ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://context.aanhet.net archive : https://bitbucket.org/phg/context-mirror/commits/ wiki : http://contextgarden.net ___
Re: [NTG-context] problem with MkIV/TeXlive/TEXMFCACHE
Hello Luigi,
you asked:
> On Fri, Aug 27, 2021 at 10:35 AM Rainer J.H. Brandt via ntg-context <
> ntg-context@ntg.nl> wrote:
>
> > Dear experts,
> >
> > I want to use ConTeXt MkIV as supplied by TeXlive 2021.
> > After installation, I ran "mtxrun --generate".
> > I also tried "context --generate".
> > Both create output in the wrong place.
> >
> > The TeXlive documentation says that ConTeXt uses TEXMFCACHE,
> > which uses the default $TEXMFSYSVAR;$TEXMFVAR in my texmf.cnf.
> > My TEXMFSYSVAR is /var/opt/texlive, but ConTeXt doesn't use it.
> > Instead, it creates /opt/texmf-var and creates its output there.
> > I don't understand why it used that path; I've never used or configured
> > it.
> >
> > How can I convice ConTeXt to use TEXMFSYSVAR?
> > [...]
>
> What does
> $> tlmgr conf
> say ?
The output is appended below and looks reasonable. In particular, it shows
that I installed under /opt/local/share/texlive and doesn't mention the
"mtxrun --generate" output path /opt/texmf-var at all.
Please note that I don't use tlmgr and also that I didn't use the TeX Live
installer. I built the binaries from their sources and then installed
the rest from the texmf archive file. I use other engines on a daily basis,
mostly pdflatex, and they work flawlessly.
Thanks, Rainer
=== version information ==
tlmgr revision 57970 (2021-02-27 15:17:34 +0100)
tlmgr using installation: /opt
executables found by searching PATH =
PATH:
/opt/local/bin:/opt/local/bin:/usr/local/bin:/usr/bin:/usr/sbin:/usr/X11R6/bin:/bin:/sbin:/Users/rjhb/doc/cvs/rjhb/perl5/bin:.:/Applications/Qt/current/clang_64/bin:/usr/X11/bin
dvipdfmx: /opt/local/bin/dvipdfmx
dvips: /opt/local/bin/dvips
fmtutil: /opt/local/bin/fmtutil
kpsewhich: /opt/local/bin/kpsewhich
luatex:/opt/local/bin/luatex
mktexpk: /opt/local/bin/mktexpk
pdftex:/opt/local/bin/pdftex
tex: /opt/local/bin/tex
tlmgr: /opt/local/bin/tlmgr
updmap:/opt/local/bin/updmap
xetex: /opt/local/bin/xetex
=== active config files ==
config.ps:/opt/local/share/texlive/texmf-dist/dvips/config/config.ps
fmtutil.cnf: /opt/local/share/texlive/texmf-dist/web2c/fmtutil.cnf
mktex.cnf:/opt/local/share/texlive/texmf-dist/web2c/mktex.cnf
pdftexconfig.tex:
/opt/local/share/texlive/texmf-dist/tex/generic/tex-ini-files/pdftexconfig.tex
texmf.cnf:/opt/local/share/texlive/texmf-dist/web2c/texmf.cnf
updmap.cfg: /opt/local/share/texlive/texmf-dist/web2c/updmap.cfg
= font map files =
kanjix.map:
/opt/local/share/texlive/texmf-dist/fonts/map/dvipdfmx/updmap/kanjix.map
pdftex.map:
/opt/local/share/texlive/texmf-dist/fonts/map/pdftex/updmap/pdftex.map
ps2pk.map:
/opt/local/share/texlive/texmf-dist/fonts/map/dvips/updmap/ps2pk.map
psfonts.map:
/opt/local/share/texlive/texmf-dist/fonts/map/dvips/updmap/psfonts.map
=== kpathsea variables ===
ENCFONTS=.:{{}/Users/rjhb/etc/texmf,/Users/rjhb/var/texmf,/Users/rjhb/lib/texmf,!!/opt/local/share/texlive/texmf-local,!!/opt/local/share/texlive/texmf-config,!!/var/opt/texlive,!!/opt/local/share/texlive/texmf-dist}/fonts/enc//
SYSTEXMF=/var/opt/texlive:/opt/local/share/texlive/texmf-local:/opt/local/share/texlive/texmf-dist
TEXCONFIG={{}/Users/rjhb/etc/texmf,/Users/rjhb/var/texmf,/Users/rjhb/lib/texmf,!!/opt/local/share/texlive/texmf-local,!!/opt/local/share/texlive/texmf-config,!!/var/opt/texlive,!!/opt/local/share/texlive/texmf-dist}/dvips//
TEXFONTMAPS=.:{{}/Users/rjhb/etc/texmf,/Users/rjhb/var/texmf,/Users/rjhb/lib/texmf,!!/opt/local/share/texlive/texmf-local,!!/opt/local/share/texlive/texmf-config,!!/var/opt/texlive,!!/opt/local/share/texlive/texmf-dist}/fonts/map/{kpsewhich,pdftex,dvips,}//
TEXMF={{}/Users/rjhb/etc/texmf,/Users/rjhb/var/texmf,/Users/rjhb/lib/texmf,!!/opt/local/share/texlive/texmf-local,!!/opt/local/share/texlive/texmf-config,!!/var/opt/texlive,!!/opt/local/share/texlive/texmf-dist}
TEXMFCONFIG=/Users/rjhb/etc/texmf
TEXMFDBS={!!/opt/local/share/texlive/texmf-local,!!/opt/local/share/texlive/texmf-config,!!/var/opt/texlive,!!/opt/local/share/texlive/texmf-dist}
TEXMFDIST=/opt/local/share/texlive/texmf-dist
TEXMFHOME=/Users/rjhb/lib/texmf
TEXMFLOCAL=/opt/local/share/texlive/texmf-local
TEXMFMAIN=/opt/local/share/texlive/texmf-dist
TEXMFSYSCONFIG=/opt/local/share/texlive/texmf-config
TEXMFSYSVAR=/var/opt/texlive
TEXMFVAR=/Users/rjhb/var/texmf
TEXPSHEADERS=.:{{}/Users/rjhb/etc/texmf,/Users/rjhb/var/texmf,/Users/rjhb/lib/texmf,!!/opt/local/share/texlive/texmf-local,!!/opt/local/share/texlive/texmf-config,!!/var/opt/texlive,!!/opt/local/share/texlive/texmf-dist}/{dvips,fonts/{enc,type1,type42,type3}}
Re: [NTG-context] Unicode normalization and Hebrew in ConTeXt
On 8/17/2021 9:46 PM, Joey McCollum wrote: Thankfully, it looks like this was just a problem with my implementation of the OpenType feature and not with ConTeXt's handling of it! (I worried that it might be ConTeXt when I saw that XeLaTeX was handing the feature correctly.) Hans graciously helped me identify the problem, and everything looks good now! Just for the record: one can best try to make a font as robust as possible and not rely on side effects (ambiguous cases). When Idris and I tested some shapers we found that there can be inconsistent results (fwiw, in a rather complex font context agreed more often with uniscribe than xetex, but in the end on ehas to make the font okay for all i guess). When we started with opentype (luatex showed up in 2005) we took uniscribe as reference so that is our benchmark. And lack of specs made us figure out things stepwise. Now, if something works in one shaper and not in another it can of course be due to bugs but it can also be that the spec is simply fuzzy and choices have been made. There is then the danger that eventually bugs become features (I assume the amount of leverage matters here, and tex has zero) which then settles it (kind of) but that doesn't man that one should gamble on it. The same is true for fontnames: don't rely too much on the heuristics hard coded in programs (e.g. fontforge has some for font names, properties, glyph names, and although that is nice for recovery, it also makes other usage hard because fighting fuzzy heuristics is hard once information is lost). Btw, a side effect of your 'issue' is that I found a way to save some memory for some fonts (for now only in lmtx) at the cost of hopefully little extra runtime. 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] Trouble with using predefined typescript files
On 6/15/2021 6:56 AM, mastermind_ x wrote: Hello everyone, I am reading the ConTexT manual’s chapter on Typography. I want to achieve a Palatino-like small font which is bolder than the default provided by ConTeXt like in some math textbooks. So I loaded the typescript files ie type-xxx stated in the chapter in turns no matter the type-xxx I load. I always got this in the log: fonts > typescripts > unknown library 'xtx' fonts > typescripts > unknown library 'gyr' selectfont > the requested font 'palatino' has no files for the 'tf' alternative, Latin Modern is used instead. selectfont > the requested font 'palatino' has no files for the 'tf' alternative, Latin Modern is used instead. selectfont > the requested font 'palatino' has no files for the 'tf' alternative, Latin Modern is used instead. selectfont > the requested font 'palatino' has no files for the 'tf' alternative, Latin Modern is used instead. \usetypescriptfile[type-xtx] \usetypescriptfile[type-gyr] \usetypescript[palatino][ec] \definefontfamily [mainface] [rm] [palatino] \definefontfamily [mainface] [ss] [palatino] \definefontfamily [mainface] [mm] [palatino] \definefontfamily [mainface] [tt] [palatino] \setupbodyfont[mainface,11pt] \starttext Hello world! \stoptext What am I missing? Are these not available right from the box like the book said? These are ‘predefined typescripts’ as the book said after all. Thanks. I use MacOS if that helps current version of ConTeXt: 2021.03.05 19:11 looks like you combine some mkii examples (xtx is a mkii xetex file, and there is no gyr) with mkiv Here is a simple way: \definefontfeature[default] [boldened-30] \definefontfeature[mathextra][boldened-20] \setupbodyfont[pagella] \startTEXpage test test $t e s t$ test \stopTEXpage the boldened-10/15/20/25/30 are predefined effects but you can roll out your own if needed 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] Issue running ConTeXt from TeX Live 2019 on Alpine Linux 3.12
= $TEXMFDOTDIR;$TEXMF/tex/{latex,generic,}//
% MLTeX.
TEXINPUTS.frlatex = $TEXMFDOTDIR;$TEXMF/tex/{french,latex,generic,}//
TEXINPUTS.frtex =
$TEXMFDOTDIR;$TEXMF/tex/{french,plain,generic,latex,}//
TEXINPUTS.mllatex = $TEXMFDOTDIR;$TEXMF/tex/{latex,generic,}//
TEXINPUTS.mltex = $TEXMFDOTDIR;$TEXMF/tex/{plain,generic,latex,}//
% e-TeX.
TEXINPUTS.elatex= $TEXMFDOTDIR;$TEXMF/tex/{latex,generic,}//
TEXINPUTS.etex = $TEXMFDOTDIR;$TEXMF/tex/{plain,generic,latex,}//
% pdfTeX.
TEXINPUTS.pdfcslatex=
$TEXMFDOTDIR;$TEXMF/tex/{cslatex,csplain,latex,generic,}//
TEXINPUTS.pdfcsplain=
$TEXMFDOTDIR;$TEXMF/tex/{csplain,plain,generic,latex,}//
TEXINPUTS.pdflatex = $TEXMFDOTDIR;$TEXMF/tex/{latex,generic,}//
TEXINPUTS.pdflatex-dev = $TEXMFDOTDIR;$TEXMF/tex/{latex-dev,latex,generic,}//
TEXINPUTS.pdfmex= $TEXMFDOTDIR;$TEXMF/tex/{mex,plain,generic,latex,}//
TEXINPUTS.utf8mex = $TEXMFDOTDIR;$TEXMF/tex/{mex,plain,generic,latex,}//
TEXINPUTS.pdftex= $TEXMFDOTDIR;$TEXMF/tex/{plain,generic,latex,}//
TEXINPUTS.pdftexinfo=
$TEXMFDOTDIR;$TEXMF/tex/{texinfo,plain,generic,latex,}//
TEXINPUTS.pdfamstex =
$TEXMFDOTDIR;$TEXMF/tex/{amstex,plain,generic,latex,}//
% pdfeTeX.
TEXINPUTS.pdfelatex = $TEXMFDOTDIR;$TEXMF/tex/{latex,generic,}//
TEXINPUTS.pdfetex = $TEXMFDOTDIR;$TEXMF/tex/{plain,generic,latex,}//
% LuaTeX.
TEXINPUTS.luatex =
$TEXMFDOTDIR;$TEXMF/tex/{luatex,plain,generic,latex,}//
TEXINPUTS.luajittex =
$TEXMFDOTDIR;$TEXMF/tex/{luatex,plain,generic,latex,}//
TEXINPUTS.luahbtex=
$TEXMFDOTDIR;$TEXMF/tex/{luatex,plain,generic,latex,}//
TEXINPUTS.luajithbtex =
$TEXMFDOTDIR;$TEXMF/tex/{luatex,plain,generic,latex,}//
TEXINPUTS.dviluatex =
$TEXMFDOTDIR;$TEXMF/tex/{luatex,plain,generic,latex,}//
TEXINPUTS.lualatex=
$TEXMFDOTDIR;$TEXMF/tex/{lualatex,latex,luatex,generic,}//
TEXINPUTS.lualatex-dev=
$TEXMFDOTDIR;$TEXMF/tex/{latex-dev,lualatex,latex,luatex,generic,}//
TEXINPUTS.luajitlatex =
$TEXMFDOTDIR;$TEXMF/tex/{lualatex,latex,luatex,generic,}//
TEXINPUTS.luahblatex =
$TEXMFDOTDIR;$TEXMF/tex/{lualatex,latex,luatex,generic,}//
TEXINPUTS.luahblatex-dev =
$TEXMFDOTDIR;$TEXMF/tex/{latex-dev,lualatex,latex,luatex,generic,}//
TEXINPUTS.luajithblatex =
$TEXMFDOTDIR;$TEXMF/tex/{lualatex,latex,luatex,generic,}//
TEXINPUTS.dvilualatex =
$TEXMFDOTDIR;$TEXMF/tex/{lualatex,latex,luatex,generic,}//
TEXINPUTS.dvilualatex-dev =
$TEXMFDOTDIR;$TEXMF/tex/{latex-dev,lualatex,latex,luatex,generic,}//
% HarfTeX.
TEXINPUTS.harftex =
$TEXMFDOTDIR;$TEXMF/tex/{harftex,luatex,plain,generic,latex,}//
TEXINPUTS.harflatex =
$TEXMFDOTDIR;$TEXMF/tex/{harflatex,harftex,lualatex,latex,luatex,generic,}//
TEXINPUTS.harflatex-dev =
$TEXMFDOTDIR;$TEXMF/tex/{latex-dev,harflatex,harftex,lualatex,latex,luatex,generic,}//
% XeTeX.
TEXINPUTS.xelatex =
$TEXMFDOTDIR;$TEXMF/tex/{xelatex,latex,xetex,generic,}//
TEXINPUTS.xelatex-dev =
$TEXMFDOTDIR;$TEXMF/tex/{latex-dev,xelatex,latex,xetex,generic,}//
TEXINPUTS.xeplain =
$TEXMFDOTDIR;$TEXMF/tex/{xeplain,eplain,plain,xetex,generic,latex,}//
TEXINPUTS.xetex = $TEXMFDOTDIR;$TEXMF/tex/{xetex,plain,generic,latex,}//
% Omega / Aleph.
TEXINPUTS.aleph = $TEXMFDOTDIR;$TEXMF/tex/{plain,generic,latex,}//
TEXINPUTS.elambda = $TEXMFDOTDIR;$TEXMF/tex/{lambda,latex,generic,}//
TEXINPUTS.eomega= $TEXMFDOTDIR;$TEXMF/tex/{plain,generic,latex,}//
TEXINPUTS.lambda= $TEXMFDOTDIR;$TEXMF/tex/{lambda,latex,generic,}//
TEXINPUTS.lamed = $TEXMFDOTDIR;$TEXMF/tex/{lambda,latex,generic,}//
TEXINPUTS.omega = $TEXMFDOTDIR;$TEXMF/tex/{plain,generic,latex,}//
% p(La)TeX.
TEXINPUTS.ptex = $TEXMFDOTDIR;$TEXMF/tex/{ptex,plain,generic,latex,}//
TEXINPUTS.platex= $TEXMFDOTDIR;$TEXMF/tex/{platex,latex,generic,}//
TEXINPUTS.platex-dev=
$TEXMFDOTDIR;$TEXMF/tex/{latex-dev,platex,latex,generic,}//
% epTeX, and use that engine for pmpost.
TEXINPUTS.eptex = $TEXMFDOTDIR;$TEXMF/tex/{ptex,plain,generic,latex,}//
TEX.pmpost = eptex
% p(La)TeX-ng
TEXINPUTS.ptex-ng =
$TEXMFDOTDIR;$TEXMF/tex/{uptex,ptex,plain,generic,latex,}//
TEXINPUTS.platex-ng = $TEXMFDOTDIR;$TEXMF/tex/{uplatex,platex,latex,generic,}//
% (e)up(La)TeX, and for upmpost
TEXINPUTS.uplatex =
$TEXMFDOTDIR;$TEXMF/tex/{uplatex,platex,latex,generic,}//
TEXINPUTS.uplatex-dev =
$TEXMFDOTDIR;$TEXMF/tex/{latex-dev,uplatex,platex,latex,generic,}//
TEXINPUTS.uptex = $TEXMFDOTDIR;$TEXMF/tex/{uptex,ptex,plain,generic,latex,}//
TEXINPUTS.euptex = $TEXMFDOTDIR;$TEXMF/tex/{uptex,ptex,plain,generic,latex,}//
TEX.upmpost = euptex
% pBibTeX bibliographies and style files.
BIBINPUTS.pbibtex = $TEXMFDOTDIR;$TEXMF/{pbibtex,bibtex}/bib//
BSTINPUTS.pbibtex = $TEXMFDOTDIR;$TEXMF/{pbibtex,bibtex}/bst//
% upBibTeX bibliographies and style files.
BIBINPUTS.upbibtex = $TEXMFDOTDIR;$TEXMF/{upbibtex,pbibtex,bibtex}/bib//
BSTINPUTS
Re: [NTG-context] Issue running ConTeXt from TeX Live 2019 on Alpine Linux 3.12
On Fri, 30 Apr 2021 at 20:53, Nicola wrote: > > This installs and configures repos for Alpine Linux 3.12. Then, > I install TeX Live as follows: > > apk add texlive-full texlive-xetex texlive-luatex texlive-dev > apk add ghostscript ghostscript-fonts ghostscript-dev > apk add graphicsmagick graphicsmagick-dev > > Then, I run `mtxrun --generate`, which exits instantly with the output > reported below. However, that is apparently not enough. I still get: > > $ context Hello-world.tex > mtxrun | unknown script 'context.lua' or 'mtx-context.lua' This sounds like a missing or misconfigured texmfcnf.lua (which should be next to texmf.cnf). This would need to be handled by the distribution (Alpine Linux devs). Can you try to locate both files and share the contents? (There may also be multiple copies of them.) Mojca ___ 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] Issue running ConTeXt from TeX Live 2019 on Alpine Linux 3.12
I'd like to run ConTeXt on Alpine Linux (ultimately, to run it on an
iPad with the iSH app). I am currently testing it with Docker. This is
what I have done:
docker pull econcz/x86-alpine-glibc:ish-import
docker run -it econcz/x86-alpine-glibc:ish-import /bin/sh
cp /etc/apk/repositories /tmp/repositories
cat /etc/os-release
ALPINE_VERSION=3.12 # Set accordingly to previous command
echo "http://nl.alpinelinux.org/alpine/v${ALPINE_VERSION}/main/; | tee
/etc/apk/repositories
echo "http://nl.alpinelinux.org/alpine/v${ALPINE_VERSION}/community/; | tee
-a /etc/apk/repositories
apk update
This installs and configures repos for Alpine Linux 3.12. Then,
I install TeX Live as follows:
apk add texlive-full texlive-xetex texlive-luatex texlive-dev
apk add ghostscript ghostscript-fonts ghostscript-dev
apk add graphicsmagick graphicsmagick-dev
Then, I run `mtxrun --generate`, which exits instantly with the output
reported below. However, that is apparently not enough. I still get:
$ context Hello-world.tex
mtxrun | unknown script 'context.lua' or 'mtx-context.lua'
$ context --version
mtxrun | unknown script 'context.lua' or 'mtx-context.lua'
$ mtxrun --version
mtxrun | ConTeXt TDS Runner Tool 1.32
mtxrun | source path
$ mtxrun --script context
mtxrun | unknown script 'context.lua' or 'mtx-context.lua'
$ luatools --generate
mtxrun | unknown script 'base.lua' or 'mtx-base.lua'
$ find / -name context.lua
/usr/share/texmf-dist/scripts/context/lua/context.lua
$ find / -name mtx-context.lua
/usr/share/texmf-dist/scripts/context/lua/mtx-context.lua
$ find / -name base.lua
[Nothing found]
$ find / -name mtx-base.lua
/usr/share/texmf-dist/scripts/context/lua/mtx-base.lua
Anyone running ConTeXt on Alpine? Any idea what is wrong?
Nicola
>mtxrun --generate
resolvers | resolving | variable 'SELFAUTOLOC' set to '/usr/bin'
resolvers | resolving | variable 'SELFAUTODIR' set to '/usr'
resolvers | resolving | variable 'SELFAUTOPARENT' set to '.'
resolvers | resolving | variable 'TEXMFCNF' set to ''
resolvers | resolving | variable 'TEXMF' set to ''
resolvers | resolving | variable 'TEXOS' set to 'usr'
resolvers | resolving |
resolvers | resolving | using configuration specification
'home:texmf/web2c;{selfautoloc:,selfautoloc:/share/texmf-local/web2c,selfautoloc:/share/texmf-dist/web2c,selfautoloc:/share/texmf/web2c,selfautoloc:/texmf-local/web2c,selfautoloc:/texmf-dist/web2c,selfautoloc:/texmf/web2c,selfautodir:,selfautodir:/share/texmf-local/web2c,selfautodir:/share/texmf-dist/web2c,selfautodir:/share/texmf/web2c,selfautodir:/texmf-local/web2c,selfautodir:/texmf-dist/web2c,selfautodir:/texmf/web2c,$SELFAUTOGRANDPARENT/texmf-local/web2c,selfautoparent:,selfautoparent:/share/texmf-local/web2c,selfautoparent:/share/texmf-dist/web2c,selfautoparent:/share/texmf/web2c,selfautoparent:/texmf-local/web2c,selfautoparent:/texmf-dist/web2c,selfautoparent:/texmf/web2c}'
resolvers | resolving |
resolvers | resolving | looking for regular 'texmfcnf.lua' on given path
'/root/texmf/web2c' from specification 'home:texmf/web2c'
resolvers | resolving | looking for regular 'texmfcnf.lua' on weird path
'/usr/bin' from specification 'selfautoloc:'
resolvers | resolving | looking for regular 'texmfcnf.lua' on given path
'/usr/bin/share/texmf-local/web2c' from specification
'selfautoloc:/share/texmf-local/web2c'
resolvers | resolving | looking for regular 'texmfcnf.lua' on given path
'/usr/bin/share/texmf-dist/web2c' from specification
'selfautoloc:/share/texmf-dist/web2c'
resolvers | resolving | looking for regular 'texmfcnf.lua' on given path
'/usr/bin/share/texmf/web2c' from specification 'selfautoloc:/share/texmf/web2c'
resolvers | resolving | looking for regular 'texmfcnf.lua' on given path
'/usr/bin/texmf-local/web2c' from specification 'selfautoloc:/texmf-local/web2c'
resolvers | resolving | looking for regular 'texmfcnf.lua' on given path
'/usr/bin/texmf-dist/web2c' from specification 'selfautoloc:/texmf-dist/web2c'
resolvers | resolving | looking for regular 'texmfcnf.lua' on given path
'/usr/bin/texmf/web2c' from specification 'selfautoloc:/texmf/web2c'
resolvers | resolving | looking for regular 'texmfcnf.lua' on weird path
'/usr' from specification 'selfautodir:'
resolvers | resolving | looking for regular 'texmfcnf.lua' on given path
'/usr/share/texmf-local/web2c' from specification
'selfautodir:/share/texmf-local/web2c'
resolvers | resolving | looking for regular 'texmfcnf.lua' on given path
'/usr/share/texmf-dist/web2c' from specification
'selfautodir:/share/texmf-dist/web2c'
resolvers | resolving | found regular configuration file
'/usr/share/texmf-dist/web2c/texmfcnf.lua'
resolvers | resolv
[NTG-context] Luatex 1.13.0 announcement.
== LuaTeX 1.13.0 2021-03-12 == This is the release for TeX live 2021. Callback for nesting level used in tracingmacros. It is is a variant of \tracingstacklevels by Petr Olsak implemented in pdftex and xetex. Two TeX January 2021 DEK buglet fixes (H.Hagen) Mark math glyphs as protected (in order to prevent processing as text in base mode). Removed width/ic compensation for traditional math code path. When restricted system commands is enabled os.setenv has no effect. Minor clean-up and bugs fixed (see ChangeLog) -- luigi ___ 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] tex live code freeze
Hi, The 2021 texlive code is currently being frozen. This means that Mojca will check-in the current context release right before tl gets deep frozen. The MKII code (mkii and mpii files) hasn't changed so it should still work well with pdftex and xetex although I admit that I haven't checked to what extend updates to those engines have side effects for context, but I assume none. Let me know if there are problems. The MKIV code (mkiv, mkvi, mpiv, lua files) has changed but not much, mostly as a side effect of the code split and move to LMTX where the focus is on now. There have been recent changes in the metafun code, but new functionality is LMTX only, simply because we use an extended library (more features). Of course there have been some bug fixes to MKIV and if you think more (bugs) should be fixed let us know. The yearly texlive release is also the 'official' yearly current release but of course after that there will be updates when needed. In these updates we don't distinguish between betas and currents: we dropped that some time ago because it was only confusing. Last/this year much of LMTX (mkxl, mpxl, lmt files) already got split and I expect that this year all the lua and mp files also will be independent so that at some point we have a more or less frozen MKIV that uses luatex (which doesn't change fundamentally apart from fixes so we don't need to adapt code to it i.e. MKIV should keep working just like MKII does with pdftex; updates to for instance fonts and languages will be applied). I get the impression that most users already moved to LMTX which helped getting it in the state it is now (thanks for all the testing). Although MKII/MKIV serves a reference for functionality, new stuff got and gets added to LMTX. I could backport some but it probably makes no sense (some is probably easy). There is of course untested code like the overload protection mechasnisms but I have that enabled on my machine (users can do that too) so I can notice side effects. The new engine (luametatex) doesn't change much. Recent changes are mostly cosmetic and I don't expect many more fundamental additions, but who knows ... (not all in there is yet used extensively) and maybe context users have interesting demands that trigger extra stuff (read: challenges me). So apart from new trickery at the tex macro end, we also reach a more stable state in LMTX. Soon I'll pick up some todo's. Some users want parallel stuff (keeps coming up), I also want to see how we can do more metafun - let me know what is missing as I'm currently in metafun mode - and go over some older lua code that started as experiment but hasn't been checked recently. I also want to cleanup the export code a bit but it's kind of boring to do and maybe we should ditch some pdf backend functionilty that adobe dropped from its viewers. And there are always manuals to complete / update ... Anyway, the current LMTX release is also a kind of yearly snapshot. So, if there is some last minute stuff that needs to be done to context MKII and MKIV before the tl code freeze, let us know. 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] composing commands
On 2/6/2021 12:01 AM, Thomas A. Schmitz wrote: On 2/5/21 10:30 PM, Hans Hagen wrote: Is this ok for you? tex error > tex error on line 6 in file ./oeps.tex: Undefined control sequence \v 4 5 \starttext 6 >> \v 7 \stoptext 8 Otared has already replied what I was thinking: would it be possible, for a certain period of time, to not stop compilation, but flag the issue on the console? When you say that such changes won't happen suddenly, this would be a wonderful compromise for me. My consolidated bibtex database began its life many many years ago, when bibtex was still pure 7bit, and you had to pepper your sources with all sorts of silly workarounds in order to get accents and umlauts and whatever you wanted. Those were the days - barefoot through the snow, and it was uphill both ways... So how did you do the greek then? I played a bit with an alternative implementation (same commands): less hash and mem, delegate more to lua. That way we can a less cost issue such a message (once only of course). There is of course a price to pay % .16 sec per 10 \"u : old method (more mkii-ish) % .25 sec per 10 \"u : new method (more lmtx-ish) (actually with mkii in pdftex we need .3 seconds, xetex freezes with 100K but needs 0.53 for 10K, luatex needs 0.18) but I'm sure you don't care much about that so I just implements a variant with warning which takes .19 seconds per 100K so it's a nice compromise. (Probably less than half of that time on your machine.) system > instead of old school '\"u' you can input the utf sequence ü (The old school narative is that context is slow, which is why we need to keep an eye on performance, right?) 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] LMTX isn't typesetting math correctly with Pagella
On Sun, Jan 17, 2021 at 10:00 PM Hans Hagen wrote:
> On 1/16/2021 12:33 AM, Hans Hagen wrote:
> > On 1/15/2021 1:33 PM, Jack Hill wrote:
> >> Hi,
> >>
> >> I've been having some trouble with ConTeXt not typesetting math
> >> correctly when using the Pagella font (I do not know if the same issue
> >> occurs with other fonts as I haven't tested them).
> >>
> >> If I compile with LMTX, the spacing between letters becomes very small
> >> so that when I type "|f|", for example, the second "|" intersects the
> >> f and looks rather ugly. However, compiling with the --luatex switch
> >> fixes these issues and the math looks nice again.
> >>
> >> Can anybody else replicate this issue, and does anybody know why it is
> >> happening?
> >>
> >> This the code I used to test:
> >>
> >> |\setupbodyfont[pagella] \starttext \startformula |f| = \sqrt{\int_0^1
> >> |f(t)|^2 \text{d}t} \stopformula \stoptext |||
> > I'll check it ... smells like some interference between newer and older
> > corrections (these gyre fonts need some special treatment).
> I uploaded lmtx.
>
> Here is the story about math:
>
> - there is traditional math, the 8 bit fonts (from Don Knuth)
> - and there is opentype math (originating at Microsoft)
>
> the eight bit fonts are all modelled after the cmr fonts so they have
> the same set of parameters, the same assumptions about family 2 and 3,
> use the same width/height/depth trickery
>
> one thing is that they lie about the width: the italic correction is
> subtracted from the width and the engine always adds it when a glyph is
> dealt with but then removes in some cases afterwards
>
> in opentype we also have italic correction but that is applied in
> specific cases; there the shapes have a real width
>
> (there are tricks to make fonts seen as opentype be treated as old
> school which work ok for virtual constructs that only use those 8 bit
> fonts but often fail for gyre fonts)
>
> now, the gust foundation fonts are a mix: they are opentype, have its
> parameters and properties but have the wrong width and assume the italic
> hackery
>
> the microsoft cambria font is the reference for opentype math (and to
> some extend microsoft word also is)
>
> afaik xetex uses the old tex approach also for opentype so that is why
> probably the old width approach works ok there but i never looked into
> it; cambria is an opentype font but probably seldom used so side effects
> will go unnoticed, also, texies often have no problem blaming microsoft,
> even when they got it right; of course we have to admit that 'moving
> forward wrt math fonts' didn't come from our community so we just have
> to follow
>
> now, when we move on (with context + luametatex) to a variants font
> scaling model, i need to adapt the math machinery to deal with that ...
> this can have side effects as you noticed but these will be dealt with
> (or fixed when something is wrong)
>
> in context we have font goodies that can handle this (widths, kerns etc)
> and we do so for at least the 'f' which also has a strange left offset
> ... i now adapted that to also serve the new (compact context font)
> model and also make sure that the smaller sizes for mkiv are handled; we
> can add more in those files, but that's also a (math) user effort
>
> to be decided is of we use the feature setting "mathkerns=yes" (this was
> a directive but i made it just a feature)
>
> Now, ideally:
>
> \enableexperiments[fonts.compact] % for the definitions
>
> should give nearly similar results (but less mem usage, less fonts
> loaded and possibly some performance gain)
>
> I also updated some test features:
>
> \definefontfeature[mathextra][staircase=yes,boundingbox=frame]
>
> as part of the general lmtx upgrading process. Only cambria (and lucida)
> have these staircase kerns and e.g. pagella and friends have a few
> defined in the font goodies but one has to do something liek this:
>
>
>
> \definefontfeature[mathextra][mathkerns=yes,staircase=yes,boundingbox=frame]
>
> more such tracers will be added in due time (and some old ones will go
> away as they lost their purpose).
>
> Hans
>
>
I got curious about those staircase kerns. Is there a simple example that
shows their effect? I greped the source, but did not find anything where I
could see a difference.
/Mikael
___
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] LMTX isn't typesetting math correctly with Pagella
On 1/16/2021 12:33 AM, Hans Hagen wrote:
On 1/15/2021 1:33 PM, Jack Hill wrote:
Hi,
I've been having some trouble with ConTeXt not typesetting math
correctly when using the Pagella font (I do not know if the same issue
occurs with other fonts as I haven't tested them).
If I compile with LMTX, the spacing between letters becomes very small
so that when I type "|f|", for example, the second "|" intersects the
f and looks rather ugly. However, compiling with the --luatex switch
fixes these issues and the math looks nice again.
Can anybody else replicate this issue, and does anybody know why it is
happening?
This the code I used to test:
|\setupbodyfont[pagella] \starttext \startformula |f| = \sqrt{\int_0^1
|f(t)|^2 \text{d}t} \stopformula \stoptext |||
I'll check it ... smells like some interference between newer and older
corrections (these gyre fonts need some special treatment).
I uploaded lmtx.
Here is the story about math:
- there is traditional math, the 8 bit fonts (from Don Knuth)
- and there is opentype math (originating at Microsoft)
the eight bit fonts are all modelled after the cmr fonts so they have
the same set of parameters, the same assumptions about family 2 and 3,
use the same width/height/depth trickery
one thing is that they lie about the width: the italic correction is
subtracted from the width and the engine always adds it when a glyph is
dealt with but then removes in some cases afterwards
in opentype we also have italic correction but that is applied in
specific cases; there the shapes have a real width
(there are tricks to make fonts seen as opentype be treated as old
school which work ok for virtual constructs that only use those 8 bit
fonts but often fail for gyre fonts)
now, the gust foundation fonts are a mix: they are opentype, have its
parameters and properties but have the wrong width and assume the italic
hackery
the microsoft cambria font is the reference for opentype math (and to
some extend microsoft word also is)
afaik xetex uses the old tex approach also for opentype so that is why
probably the old width approach works ok there but i never looked into
it; cambria is an opentype font but probably seldom used so side effects
will go unnoticed, also, texies often have no problem blaming microsoft,
even when they got it right; of course we have to admit that 'moving
forward wrt math fonts' didn't come from our community so we just have
to follow
now, when we move on (with context + luametatex) to a variants font
scaling model, i need to adapt the math machinery to deal with that ...
this can have side effects as you noticed but these will be dealt with
(or fixed when something is wrong)
in context we have font goodies that can handle this (widths, kerns etc)
and we do so for at least the 'f' which also has a strange left offset
... i now adapted that to also serve the new (compact context font)
model and also make sure that the smaller sizes for mkiv are handled; we
can add more in those files, but that's also a (math) user effort
to be decided is of we use the feature setting "mathkerns=yes" (this was
a directive but i made it just a feature)
Now, ideally:
\enableexperiments[fonts.compact] % for the definitions
should give nearly similar results (but less mem usage, less fonts
loaded and possibly some performance gain)
I also updated some test features:
\definefontfeature[mathextra][staircase=yes,boundingbox=frame]
as part of the general lmtx upgrading process. Only cambria (and lucida)
have these staircase kerns and e.g. pagella and friends have a few
defined in the font goodies but one has to do something liek this:
\definefontfeature[mathextra][mathkerns=yes,staircase=yes,boundingbox=frame]
more such tracers will be added in due time (and some old ones will go
away as they lost their 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
-
___
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] a new book has been published, made with the help of ConTeXt
On 20.12.20 01:09, Pablo Rodriguez wrote: > Congratulations for the release of your book, Robert. > It is really a pleasure to be able to page through the final PDF. >> >> [...] ConTeXt was The Solution [...]. > > Would it be the [features=kannada-one] also a solution for a similar book? I submitted the PDF to the publisher already last August. At the time I was not yet aware of this happy development in MkIV, and so the book was made with MkII using XeTeX as the backend. But in view of the various advances that were made with MkIV, I hope to make the next book using that one. > I’d like to know if something would be missing (besides the hyphenation > patterns). For the recent book I had no great need for Indic hyphenation patterns, because all the Kannada text fragments were quite short and hyphenation could be done manually. But for longer texts (as I have in mind in an upcoming book), the patterns will be most welcome. > Congratulations again for your excellent book, Thank you! Robert ___ 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] a new book has been published, made with the help of ConTeXt
Dear readers, With great joy and a sense of relief I can now announce that my latest book, _A Manual of Modern Kannada_ by Robert Zydenbos (Heidelberg / Berlin: CrossAsia E-Publishing, 2020), a teaching manual of the Kannada language (Kannada belongs to the Dravidian family of languages, mainly spoken in southern India; also in the city of Bangalore, the 'Silicon Valley of India') has been published. It is an Open Access publication, which means it is available as a gratis download in PDF format from https://crossasia-books.ub.uni-heidelberg.de/xasia/catalog/book/736 (the clickable button “Buch herunterladen” means “Download book”; “Buch kaufen” means “Buy book”, for those who want a real book on paper). I was working on this book for the past few years and decided that the only affordably sensible way to achieve presentable results would be to use TeX, but plain TeX was too cumbersome, and in LaTeX the tables were difficult (and the book has many, many tables in various shapes and sizes). ConTeXt was The Solution (and has been duly mentioned in the technical note at the end of the book, with special thanks to Hans, Wolfgang and Pablo for valuable suggestions). For those who are curious how I used ConTeXt MkII with the XeTeX backend, a sample chapter is available at http://e.pc.cd/XlhotalK (and then click on "Direkt herunterladen"). Robert Zydenbos ___ 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] \XeTeX\ misbehaving
Hans,
just accidentally, I discovered that \XeTeX\ misbehaves:
\starttext
\input{zapf} \XETEX\ \input{knuth}
\stoptext
BTW, this is the MWE after I saw
http://www.pragma-ade.com/general/manuals/luametatex.pdf#page=15.
I hope it helps,
Pablo
--
http://www.ousia.tk
___
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] new upload
Hi, I'm planning in the next few weeks to retire my 2012 16GB Mac mini which has served me well with ConTeXt (and other software) over these past few years. I was planning on getting the new entry level MAC min M1 with 8GB unified memory but I see that there will be no ConTeXt binaries for these new M1 chip Macs. Would it be possible for a ConTeXt user like myself to build the binaries on my proposed new Mac? I'm not a computer professional. Best Wishes Keith McKay On 24/11/2020 19:07, Hans Hagen wrote: Hi, A new upload. Mojca upgraded the build manager and we also updated some machines so all binaries (platforms) should be in sync now. (No binaries for apples M1 and microsofts SQ2 as we don't have these machines, so just good old intel and arm it is.) On my rusty laptop the luametatex manual takes between 10 and 10.5 sec (depending on load). On the raspberry pi 64 bit it takes 32.5 sec (ubuntu, ssd on usb 3). The Windows Linux Subsystem (version 1) takes some 11.5 seconds and the domotica fitlet with a low power AMD A10 needs 27.5 sec.) The ratios match measurements of a while ago. In the meantime the format file got smaller, memory more dynamic and the mem footprint also smaller. I expect a modern intel laptop cpu to need some 5 seconds and a decent desktop less but who knows. It's not easy to squeeze out more (the bottleneck is in the lua code as the (con)tex(t) code is pretty efficient so we pay a price for flexibility). (In the process I saw that I bugged the xetex logo but that has to wait for a next upload. Hardly critital I suspect.) 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 ___ ___ 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] new upload
Great. Made a clean install from scratch and now metafun manual compiles great at first run: mkiv lua stats > used engine:* luametatex version: 2.0803, functionality level: 20201123*, format id: 547, compiler: gcc mkiv lua stats > tex properties: 740024 hash slots used of 2097152, approximate memory usage: 44 MB mkiv lua stats > lua properties: engine: lua 5.4, used memory: 140 MB, ctx: 123 MB, max: 123 MB, hash chars: min(64,40), symbol mask: utf (τεχ) mkiv lua stats > runtime: 20.182 seconds, 396 processed pages, 396 shipped pages, 19.621 pages/second giulio b. On Tue, Nov 24, 2020 at 8:07 PM Hans Hagen wrote: > Hi, > > A new upload. Mojca upgraded the build manager and we also updated some > machines so all binaries (platforms) should be in sync now. (No binaries > for apples M1 and microsofts SQ2 as we don't have these machines, so > just good old intel and arm it is.) > > On my rusty laptop the luametatex manual takes between 10 and 10.5 sec > (depending on load). On the raspberry pi 64 bit it takes 32.5 sec > (ubuntu, ssd on usb 3). The Windows Linux Subsystem (version 1) takes > some 11.5 seconds and the domotica fitlet with a low power AMD A10 needs > 27.5 sec.) The ratios match measurements of a while ago. In the meantime > the format file got smaller, memory more dynamic and the mem footprint > also smaller. I expect a modern intel laptop cpu to need some 5 seconds > and a decent desktop less but who knows. It's not easy to squeeze out > more (the bottleneck is in the lua code as the (con)tex(t) code is > pretty efficient so we pay a price for flexibility). > > (In the process I saw that I bugged the xetex logo but that has to wait > for a next upload. Hardly critital I suspect.) > > 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 > > ___ > ___ 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] new upload
Hi, A new upload. Mojca upgraded the build manager and we also updated some machines so all binaries (platforms) should be in sync now. (No binaries for apples M1 and microsofts SQ2 as we don't have these machines, so just good old intel and arm it is.) On my rusty laptop the luametatex manual takes between 10 and 10.5 sec (depending on load). On the raspberry pi 64 bit it takes 32.5 sec (ubuntu, ssd on usb 3). The Windows Linux Subsystem (version 1) takes some 11.5 seconds and the domotica fitlet with a low power AMD A10 needs 27.5 sec.) The ratios match measurements of a while ago. In the meantime the format file got smaller, memory more dynamic and the mem footprint also smaller. I expect a modern intel laptop cpu to need some 5 seconds and a decent desktop less but who knows. It's not easy to squeeze out more (the bottleneck is in the lua code as the (con)tex(t) code is pretty efficient so we pay a price for flexibility). (In the process I saw that I bugged the xetex logo but that has to wait for a next upload. Hardly critital I suspect.) 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] Adding built-in support for Serbian language
Dear Ivan, On Fri, 30 Oct 2020 at 11:32, Ivan Pešić wrote: > > Hello all, > I have recently started using ConTeXt. Welcome! > I've found that the distribution > includes a proper (cyrillic) hyphenation file for Serbian language, I would say that this needs to be changed/improved. There's no reason why it wouldn't load both scripts at the same time (at least for Unicode engines, which is the only thing that's currently supported anyway). This is what XeTeX loads, for example: https://github.com/hyphenation/tex-hyphen/blob/master/hyph-utf8/tex/generic/hyph-utf8/loadhyph/loadhyph-sr-latn.tex#L25 \input hyph-sh-latn.tex \input hyph-sh-cyrl.tex That is: it loads both patterns at the same time. Hans, would you be willing to merge two sets of hyphenation patterns together? Alternatively maybe we could prepare hyph-sh.pat.txt on the hyph-utf8 side? I'm actually not sure why we didn't do that already, but maybe it was because we have two sets of cyrillic patterns and it has never been a clear cut which ones to take. The author of hyph-sh-[latn|cyrl] says that his patterns should work universally for multiple languages (they are relatively old), but they were initially only released for the Latin scripts. Later another author wanted to have support for Cyrillic script and prepared his own patterns (I'm no longer sure whether they were partially based on the other ones) without the Latin alternative. In Xe(La)TeX and Lua(La)TeX we use the "sh" patterns for both, for consistency reasons, among others. (You likely want the same word to be hyphenated in the same way in both scripts). > but a complete language support is still not implemented. Therefore, > I've added what I think is required, did some testing by putting changed > files in my texmf-local, and the result looks fine. Awesome, thank you. > There is only one thing that requires a decision from the development team. > Serbian language uses two scripts: cyrillic and latin. Context language > codes are using 2 letters for identification. So I'm not sure how to > include both scripts. (Unless has plans to transliterate the translations on the fly :) there should be two independent files. One should use the code sr-latn and the other one sr-cyrl. Two letter code simply doesn't work in this situation and we should not even try to support one single script, or even attempt to decide which one should be the default one. Both should be supported equally well. > What I'm sending now is a cyrillic script implementation, using the code > "sr". > > It is trivial to generate (completely automatic) latin script version of > these changes, once it is decided how to label it. Would you be willing to also prepare the latin one then? The codes should be sorted out by Hans (potentially with some help), but we definitely want to use "sr-latn" and "sr-cyrl". For the longer names there is some more freedom. LaTeX uses "serbianl" and "serbianc", I think, but I believe we can come up with something nicer. Maybe something along the lines of the following? \mainlanguage[serbian][script=latn] or \mainlanguage[serbian-latin] \mainlanguage[serbian-cyrillic] No clue, really. Thank you, Mojca (PS: I would say that adding support for transliteration of the text from one script to the other would be a really nice feature. Then you could type your text for a book once and have it typeset in both versions without any extra effort :) ___ 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] Join Foundation to Support ConTeXt for the next 50 Years
On 17/10/20, 10:46, Suminda Sirinath Salpitikorala Dharmasena wrote: > Hello, > > In order to keep ConTeXt maintained for the very long term future, I am > wondering if there a possibility to join a foundation like the Apache > Software Foundation, Linux Foundation, etc. https://group.contextgarden.net/ > Also perhaps more to a more liberal license so there can be commercial use > of ConTeXt with some of it trickling to as code contributions, wider usage > which may further translate to support and consultancy work for those > familiar with ConTeXt. If commercial system uses ConTeXt as part of their > system there is a chance that is it is in their best interest to maintain > it also long as these systems are in operation. The main application of ConTeXt is producing PDFs and since these outputs are not “derived works” (using the wording of the GPL), the license terms of ConTeXt do not apply to them. I don't think anyone is actually modifying the ConTeXt core and even then, as long as you don't distribute binaries but only PDFs you don't have to publish the source. > Also perhaps it might be best than just depend on TeX maybe fork TeX and > improve it in a ConTeXt dependent way. This way ConTeXt more feature-rich > and easier to maintain than carrying the technical burden of TeX. There are > system like SILE typesetter (https://sile-typesetter.org/) which are > developed from the ground up and also The Tectonic Typesetting System ( > https://tectonic-typesetting.github.io/en-US/). What are you even talking about? ConTeXt has been using a forked TeX engine for at least a decade. LuaTeX is solely developed by and for the ConTeXt people. BTW, SILE is something completely different (and can't do math yet) and Tectonic is just a thin wrapper around XeTeX. Cheers, Henri > This is just some ideas which I thought might be worthwhile considering. > > Suminda > ___ > 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 > ___ ___ 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] About vertical typesetting in ConTeXt
Hi, list. I've found a (sort of) way to do LTL typesetting in Lua(La)TeX
based on "chickenize", a LuaTeX package. The font used is available here;
http://www.mongolfont.com/en/font/mnglwhiteotf.html
%Just for testing in LaTeX
\documentclass{article}
\usepackage{luacode}
\usepackage{fontspec}
\setmainfont{Mongolian White}[Renderer=Harfbuzz,Script=Mongolian]
\begin{luacode*}
-- How do I do this in ConTeXt?
userdata = userdata or {}
userdata.mongolian = function(head)
--Ugly hackish line rotation
rot = node.new(node.id("whatsit"),node.subtype("pdf_literal"))
rot2 = node.new(node.id("whatsit"),node.subtype("pdf_literal"))
for line in node.traverse_id(0,head) do
w = line.width/65536*0.99625
rot.data = "-1 0 0 -1 "..w.." 0 cm"
rot2.data = "-1 0 0 -1 "..-w.." 0 cm"
line.head = node.insert_before(line.head,line.head,node.copy(rot))
node.insert_after(line.head,node.tail(line.head),node.copy(rot2))
end
return head
end
\end{luacode*}
\def\startmongolian{\directlua{luatexbase.add_to_callback("post_linebreak_filter",
userdata.mongolian, "mongolian")}}
\def\stopmongolian{%
\par\directlua{luatexbase.remove_from_callback("post_linebreak_filter",
"mongolian")}%
}
\usepackage{graphicx}
\begin{document}
\rotatebox{90}{%
\parbox{8cm}{%
\startmongolian
\begin{flushleft}
ᠣᠢᠷᠠ ᠵᠢᠨ ᠡᠳᠦᠷ᠂ ᠦᠪᠦᠷ ᠮᠣᠩᠭᠣᠯ ᠦᠨ ᠰᠢᠯᠢ ᠵᠢᠨ ᠭᠣᠣᠯ ᠠᠢᠮᠠᠭ ᠦᠨ ᠰᠢᠯᠣᠭᠣᠨ ᠬᠦᠬᠡ
ᠬᠣᠰᠢᠭᠣᠨ ᠦ ᠰᠢᠭᠦᠬᠦ ᠬᠣᠷᠢᠶᠠ ᠨᠢᠭᠡᠨ ᠬᠦᠴᠦᠷᠬᠡᠭᠯᠡᠨ ᠨᠦᠵᠢᠳᠯᠡᠭᠰᠡᠨ ᠶᠠᠯᠠᠲᠣ ᠬᠡᠷᠡᠭ ᠲᠦ
ᠰᠢᠭᠦᠯᠲᠡ ᠬᠢᠪᠡ᠃ ᠰᠢᠭᠦᠨ ᠲᠠᠰᠣᠯᠣᠯᠳᠠ ᠪᠠᠷ᠂ ᠵᠠᠭᠠᠯᠳᠣᠭᠳᠠᠭᠴᠢ ᠡᠷᠬᠢᠮᠲᠦ ᠵᠢ ᠬᠦᠴᠦᠷᠭᠡᠭᠯᠡᠨ᠂
ᠨᠦᠵᠢᠳᠯᠡᠭᠰᠡᠨ ᠶᠡᠯᠡ ᠪᠡᠷ ᠭᠣᠷᠪᠠᠨ ᠵᠢᠯ ᠦᠨ ᠬᠣᠭᠣᠴᠠᠭᠠ ᠲᠠᠢ ᠬᠣᠷᠢᠬᠣ ᠡᠷᠡᠭᠦᠦ ᠪᠡᠷ
ᠰᠢᠳᠬᠡᠭᠰᠡᠨ ᠪᠠᠢᠨᠠ᠃
\end{flushleft}
\stopmongolian
}
}
\end{document}
I can rotate boxes in ConTeXt using other methods than those used in LaTeX.
However, my main concern is about "translating" the Lua(La)TeX piece to be
used in ConTeXt. I've read about "finalizers" in the CLD manual and
somewhere online, but I don't know how to access to
node.subtype("pdf_literal"). I'll be happy to know about a better solution
if ConTeXt offers it so it is accessible to other users. Thank you in
advance.
Regards,
Jairo
El mié., 10 de jun. de 2020 a la(s) 03:11, Jairo A. del Rio (
jairoadelr...@gmail.com) escribió:
> I totally ignored this document until now. As it looks really promising
> (to me), I'll make some attempts first. In my almost-one-year experience
> with ConTeXt, a manual or a discussion in the list usually foreshadows a
> solution. ConTeXt never ceases to amaze me with its tricks and quirks.
> Thank you very much, Hans.
>
> Jairo :)
>
> El mié., 10 de jun. de 2020 a la(s) 02:30, Hans Hagen (j.ha...@xs4all.nl)
> escribió:
>
>> On 6/10/2020 7:49 AM, Jairo A. del Rio wrote:
>> > Hi list! I'm curious about vertical typesetting in ConTeXt. As far as I
>> > know, LuaTeX supports four text directions, but LTL is broken for
>> Manchu
>> > script (letters are displayed unjoined in LTL mode) and LuaMetaTeX does
>> > not support vertical directions anymore, at least as primitives.
>> >
>> > I found the following solution:
>> >
>> > https://tex.stackexchange.com/a/140972/193767
>> > I reproduce the code (in XeLaTeX), just in case
>> >
>> > |% !TEX TS-program =
>> >
>> xelatex\documentclass{scrartcl}\usepackage{fontspec}\newfontfamily{\dcw}[]{DaicingWhite}%\begin{document}\noindentLine
>>
>> > above\\% to demonstrate that the lines are being stacked as
>> > normal\rotatebox{-90}{%\XeTeXupwardsmode1\\% successive lines will be
>> > stacked upwards instead of downwards\begin{minipage}{4em}% this will be
>> > the vertical length of the Mongolian section{\dcw% Font: Daicing White1
>> > ᠮᠠᠨᠵᡠ ᡤᡳᠰᡠᠨ\\% direct Unicode input of Manchu letters2 ᠮᠠᠨᠵᡠ ᡤᡳᠰᡠᠨ }%
>> > End font\end{minipage}\XeTeXupwardsmode0 }% End rotatebox\noindentLine
>> > underneath \end{document}|
>> >
>> >
>> > and I see XeTeX uses the primitive |\XeTeXupwardsmodeand some other
>> > tricks to get the proper display of Manchu text, so maybe MKII can do
>> > the magic using XeTeX as an engine. How would one use ConTeXt MKIV for
>> > this task? Is it possible to emulate \XeTeXupwardsmode in ConTeXt as a
>> > first step? Thank you very much.
>> I admit that I have no clue about what xetex does in that departmentbut
>> you're right that in lmtx the vertical directions are not supported. The
>> main reason is that it didn't really integrates well in the way pages
>> are constructed.
>>
>> Vertical typesetting (afaiks) involves two things: one character wide
>> columns and rotated glyphs. The first can be handled by the macro
>> package
Re: [NTG-context] About vertical typesetting in ConTeXt
On 6/10/2020 7:49 AM, Jairo A. del Rio wrote:
Hi list! I'm curious about vertical typesetting in ConTeXt. As far as I
know, LuaTeX supports four text directions, but LTL is broken for Manchu
script (letters are displayed unjoined in LTL mode) and LuaMetaTeX does
not support vertical directions anymore, at least as primitives.
I found the following solution:
https://tex.stackexchange.com/a/140972/193767
I reproduce the code (in XeLaTeX), just in case
|% !TEX TS-program =
xelatex\documentclass{scrartcl}\usepackage{fontspec}\newfontfamily{\dcw}[]{DaicingWhite}%\begin{document}\noindentLine
above\\% to demonstrate that the lines are being stacked as
normal\rotatebox{-90}{%\XeTeXupwardsmode1\\% successive lines will be
stacked upwards instead of downwards\begin{minipage}{4em}% this will be
the vertical length of the Mongolian section{\dcw% Font: Daicing White1
ᠮᠠᠨᠵᡠ ᡤᡳᠰᡠᠨ\\% direct Unicode input of Manchu letters2 ᠮᠠᠨᠵᡠ ᡤᡳᠰᡠᠨ }%
End font\end{minipage}\XeTeXupwardsmode0 }% End rotatebox\noindentLine
underneath \end{document}|
and I see XeTeX uses the primitive |\XeTeXupwardsmodeand some other
tricks to get the proper display of Manchu text, so maybe MKII can do
the magic using XeTeX as an engine. How would one use ConTeXt MKIV for
this task? Is it possible to emulate \XeTeXupwardsmode in ConTeXt as a
first step? Thank you very much.
I admit that I have no clue about what xetex does in that departmentbut
you're right that in lmtx the vertical directions are not supported. The
main reason is that it didn't really integrates well in the way pages
are constructed.
Vertical typesetting (afaiks) involves two things: one character wide
columns and rotated glyphs. The first can be handled by the macro
package and the second by a combination of engine and macro package.
Already for quite a while there are the basics for a more advanced
vertical subsystem but it's typically one of these things that I explore
and then set aside till some users show up who need it and are willing
to spend time on discussing and testing intertfaces. After all, most of
this tex stuff is kind of a hobby and it's easy to find new interesting
experiments.
Anyway, you can get some ideas in chapter 6 of:
http://www.pragma-ade.com/general/manuals/followingup.pdf
but as said, probably no one ever read that. The question isnot so much
if it can be done, but how to integrate it.
(There's more stuff waiting for being used but we leave that for users
to run into and demand support 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
-
___
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] About vertical typesetting in ConTeXt
Hi list! I'm curious about vertical typesetting in ConTeXt. As far as I
know, LuaTeX supports four text directions, but LTL is broken for Manchu
script (letters are displayed unjoined in LTL mode) and LuaMetaTeX does not
support vertical directions anymore, at least as primitives.
I found the following solution:
https://tex.stackexchange.com/a/140972/193767
I reproduce the code (in XeLaTeX), just in case
% !TEX TS-program =
xelatex\documentclass{scrartcl}\usepackage{fontspec}\newfontfamily{\dcw}[]{DaicingWhite}%\begin{document}\noindent
Line above\\% to demonstrate that the lines are being stacked as
normal\rotatebox{-90}{%\XeTeXupwardsmode1\\% successive lines will be
stacked upwards instead of downwards\begin{minipage}{4em}% this will
be the vertical length of the Mongolian section{\dcw% Font: Daicing
White
1 ᠮᠠᠨᠵᡠ ᡤᡳᠰᡠᠨ\\% direct Unicode input of Manchu letters
2 ᠮᠠᠨᠵᡠ ᡤᡳᠰᡠᠨ}% End font\end{minipage}\XeTeXupwardsmode0}% End rotatebox
\noindent
Line underneath\end{document}
and I see XeTeX uses the primitive \XeTeXupwardsmode and some other tricks
to get the proper display of Manchu text, so maybe MKII can do the magic
using XeTeX as an engine. How would one use ConTeXt MKIV for this task? Is
it possible to emulate \XeTeXupwardsmode in ConTeXt as a first step? Thank
you very much.
Jairo :D
___
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] Retrieving original value of enviroment variable HOME
Hello, Hans,
I've just renewed the Ctx Beta installation, but 'environment.oldhome'
seems be unavailable.
Was I "too quick" with renewing Ctx?
Testing sample:
\starttext
Ahoj
\startluacode
context(environment.oldhome or "??")
\stopluacode
\stoptext
- prints "??".
I also attache the "status-of-update.lua" and the batch
"first-setup.bat" (maybe a bit obsolete, but working so far) I used to
renew Ctx.
Also result of "dir /s" is available here (~84 k packed):
http://leteckaposta.cz/302654804
What am I doing wrong?
Best regards,
Lukas
On 2020-05-08 14:18, Hans Hagen wrote:
You can check it. Btw, when you're using lmtx there should be no real
differences between for instance unix and windows, although on windows
lmtx does support wide characters in environment variables, command
line arguments, filenames, filelinks etc. (not that that matters much
as one will seldom use more than ascii). Specific environment
variables like HOME are a bit tricky on windows as they come in
variants, so let me know if some more magic is needed.
Hans
\starttext
Ahoj
\startluacode
context(environment.oldhome or "??")
\stopluacode
\stoptext
ChkEnv.pdf
Description: Adobe PDF document
-- generator : luat-sta.lua
-- state tag : whatever
return {
["context"]={
["version"]="beta",
},
["engines"]={
["luatex"]=true,
["pdftex"]=true,
["xetex"]=true,
},
["formats"]={
["cont-en"]=true,
["cont-nl"]=true,
["metafun"]=true,
},
["info"]={
["comment"]="this file contains the settings of the last 'mtxrun --script
update' run",
["count"]=138,
["date"]="2020-05-10 11:59:36",
["runtime"]=94.039,
["version"]=0.1,
},
["modules"]={
["all"]=true,
},
["paths"]={
["root"]="d:\\Ctx-Beta\\tex",
},
["platforms"]={
["mswin"]=true,
["win64"]=true,
},
["repositories"]={
["current"]=true,
},
["rsync"]={
["flags"]={
["delete"]="--delete",
["normal"]="-rpztlv",
},
["module"]="minimals",
["program"]="rsync",
["server"]="contextgarden.net::",
},
}@echo off
setlocal
echo okay > ok.log
ruby -e "File.delete('ok.log')"
if not exist "ok.log" goto okay
echo.
echo You need to install Ruby first (if you want to use pdfTeX or XeTeX).
echo Fetching files anyway.
echo.
:okay
set OWNPATH=%~dp0
set CONTEXTROOT=%OWNPATH%tex
set PATH=%OWNPATH%bin;%CONTEXTROOT%\texmf-mswin\bin;%PATH%
set CYGWIN=nontsec
rsync -av --exclude 'rsync.exe' --exclude 'cygwin1.dll' --exclude 'cygiconv-2.dll' rsync://contextgarden.net/minimals/setup/mswin/bin/ bin
mtxrun --script ./bin/mtx-update.lua --force --update --make --engine=all --context=beta --texroot=%CONTEXTROOT% %*
echo.
echo When you want to use context, you need to initialize the tree with:
echo.
echo %CONTEXTROOT%\setuptex.bat %CONTEXTROOT%
echo.
echo You can associate this command with a shortcut to the cmd prompt.
echo.
if not exist "ok.log" goto end
echo.
echo If you want to use pdfTeX or XeTeX you need to install Ruby first.
echo Remake formats or rerun this script afterwards.
echo.
del /q ok.log
:end
endlocal
___
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] lmtx vs mkiv
Hans Hagen schrieb am 03.04.2020 um 11:07: Hi, One problem of mixed usage of mkiv (with luatex) and lmtx (with luametatex) is that in the later we use a different (initial) context runner. Basically all platforms are now handled the same (in mkiv there was a stub and no texlua, in unix something shebang with texlua because of argument passing limitations). However, the main context script can be told to use a specific engine: context --luatex foo.tex so in principle one can use both lmtx and mkiv with the same binary tree, given that luametatex and luatex are both present and that luametatex is in charge. For that reason the latest lmtx installer now (for the time being) also includes the luatex binary (plus mkiv files needed) so that one can install lmtx and run both engines. Instead of the --luatex switch one can also force the engine in the usual way with "% engine=luatex" at the top line of the source file (but no pdftex and xetex in this installer). FWIW, the lmtx installation ships with the latest experimental luatex binary but normally that should not have consequences, but it does permits testing occasional updates. Hans The binary for Windows 64bit is missing (or in a different folder) on the server because I get the following message as content for luatex.exe 404 Not Found Not Found The requested URL /build/luatex/x86_64-w64-mingw32/luatex.exe was not found on this server. 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] lmtx vs mkiv
> Am 03.04.2020 um 11:07 schrieb Hans Hagen : > > For that reason the latest lmtx installer now (for the time being) also > includes the luatex binary (plus mkiv files needed) so that one can install > lmtx and run both engines. Instead of the --luatex switch one can also force > the engine in the usual way with "% engine=luatex" at the top line of the > source file (but no pdftex and xetex in this installer). I updated LMTX on MacOSX 10.13 today. The luatex binary in not executable, thus when I run axel$ context --luatex --version mtx-context | redirect luametatex -> luatex: luatex --luaonly "/usr/local/texlive/LMTX/tex/texmf-osx-64/bin/mtxrun.lua" --script mtx-context --luatex --version --redirected mtx-context | ConTeXt Process Management 1.02 mtx-context | mtx-context | main context file: /Volumes/Macintosh HD/usr/local/texlive/2019/texmf-dist/tex/context/base/mkiv/context.mkiv mtx-context | current version: 2019.03.21 21:39 it picks up the TeX-Live version. after I axel$ chmod 744 luatex I get the correct version: axel$ context --luatex --version mtx-context | redirect luametatex -> luatex: luatex --luaonly "/usr/local/texlive/LMTX/tex/texmf-osx-64/bin/mtxrun.lua" --script mtx-context --luatex --version --redirected mtx-context | ConTeXt Process Management 1.03 mtx-context | mtx-context | main context file: /Volumes/Macintosh HD/usr/local/texlive/LMTX/tex/texmf-context/tex/context/base/mkiv/context.mkiv mtx-context | current version: 2020.04.03 10:31 mtx-context | main context file: /Volumes/Macintosh HD/usr/local/texlive/LMTX/tex/texmf-context/tex/context/base/mkiv/context.mkxl mtx-context | current version: 2020.04.03 10:31 Greetings Axel ___ 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] lmtx vs mkiv
Hi, One problem of mixed usage of mkiv (with luatex) and lmtx (with luametatex) is that in the later we use a different (initial) context runner. Basically all platforms are now handled the same (in mkiv there was a stub and no texlua, in unix something shebang with texlua because of argument passing limitations). However, the main context script can be told to use a specific engine: context --luatex foo.tex so in principle one can use both lmtx and mkiv with the same binary tree, given that luametatex and luatex are both present and that luametatex is in charge. For that reason the latest lmtx installer now (for the time being) also includes the luatex binary (plus mkiv files needed) so that one can install lmtx and run both engines. Instead of the --luatex switch one can also force the engine in the usual way with "% engine=luatex" at the top line of the source file (but no pdftex and xetex in this installer). FWIW, the lmtx installation ships with the latest experimental luatex binary but normally that should not have consequences, but it does permits testing occasional updates. 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] Question to installation ConTeXt from TeXlive
Hans, thanks for the help. I wikified it, see https://wiki.contextgarden.net/Windows_10_64_bit_Installation_2019_--_how_to_install_from_TeXlive. Would be anybody so kind and check the English collection names at some time? (I have got no computer with W.) Best wishes, Tomáš Tue, Feb 18, 2020 ve 02:56:47PM +0100 Hans Hagen napsal(a): # On 2/18/2020 1:28 PM, Tomas Hala wrote: # >Hi all, # > # >when one (eg. student) decides for customizing the Windows installation from TeXlive, # >24 items will appear in the group of packages list. # > # >Because I have no experience with W. installations, I would like to ask # >which of them are relevant or possible to use with ConTeXt MkIV (on W.). # >(The aim is not to install unusable stuff.) # > # >Legend: # >%=I guess no +=I guess yes ?=I am not sure # > # >[translated from the Czech version of the Installer] # > # >+ Additional fonts # >+ ConTeXt etc. # >+ LuaTeX # >+ MetaPost and Metafont # # probably not as we have mplib buil tin # # >+ Recommended Fonts # >+ TeXWorks # # probably not unless you use it # # >+ Auxillary programmes for W. # # mkiv ... i guess nothing additional makes sense # # >% Additional for LaTeX # >% Art Fields # >% Basic LaTeX # >% Basic (La)TeX # >% Publishing styles # >% Recommended LaTeX # >% Typesetting Games # # >? Additional formats # # no # # >? Auxillary programmes for TeX # # no # # >? Graphics, images, diagrams # # probably no # # >? Math, nat. sci., comp. sci. # # no, context stuff comes with context already # # >? Music # # unlikely # # >? Necessary programmes and files # # what is that # # >? PSTricks # # only if used # # >? Additional for BibTeX # # no # # >? SW for graphics and fonts # # no # # >? XeTeX etc. # # not for 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 # - Tomáš Hála Mendelova univerzita, Provozně ekonomická fakulta, ústav informatiky Zemědělská 1, CZ-613 00 Brno, tel. +420 545 13 22 28 http://akela.mendelu.cz/~thala ___ 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] Question to installation ConTeXt from TeXlive
On 2/18/2020 1:28 PM, Tomas Hala wrote: Hi all, when one (eg. student) decides for customizing the Windows installation from TeXlive, 24 items will appear in the group of packages list. Because I have no experience with W. installations, I would like to ask which of them are relevant or possible to use with ConTeXt MkIV (on W.). (The aim is not to install unusable stuff.) Legend: %=I guess no +=I guess yes ?=I am not sure [translated from the Czech version of the Installer] + Additional fonts + ConTeXt etc. + LuaTeX + MetaPost and Metafont probably not as we have mplib buil tin + Recommended Fonts + TeXWorks probably not unless you use it + Auxillary programmes for W. mkiv ... i guess nothing additional makes sense % Additional for LaTeX % Art Fields % Basic LaTeX % Basic (La)TeX % Publishing styles % Recommended LaTeX % Typesetting Games ? Additional formats no ? Auxillary programmes for TeX no ? Graphics, images, diagrams probably no ? Math, nat. sci., comp. sci. no, context stuff comes with context already ? Music unlikely ? Necessary programmes and files what is that ? PSTricks only if used ? Additional for BibTeX no ? SW for graphics and fonts no ? XeTeX etc. not for 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 - ___ 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] Question to installation ConTeXt from TeXlive
Hi all, when one (eg. student) decides for customizing the Windows installation from TeXlive, 24 items will appear in the group of packages list. Because I have no experience with W. installations, I would like to ask which of them are relevant or possible to use with ConTeXt MkIV (on W.). (The aim is not to install unusable stuff.) Legend: %=I guess no +=I guess yes ?=I am not sure [translated from the Czech version of the Installer] + Additional fonts + ConTeXt etc. + LuaTeX + MetaPost and Metafont + Recommended Fonts + TeXWorks + Auxillary programmes for W. % Additional for LaTeX % Art Fields % Basic LaTeX % Basic (La)TeX % Publishing styles % Recommended LaTeX % Typesetting Games ? Additional formats ? Auxillary programmes for TeX ? Graphics, images, diagrams ? Math, nat. sci., comp. sci. ? Music ? Necessary programmes and files ? PSTricks ? Additional for BibTeX ? SW for graphics and fonts ? XeTeX etc. Thanks in advance. (After completion I can put it on the wiki.) Best wishes, Tomáš ___ 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] beta vs current
On 1/30/2020 9:56 PM, Henri Menke wrote: On 1/31/20 8:37 AM, Aditya Mahajan wrote: On Thu, 30 Jan 2020, Hans Hagen wrote: Hi, Already for quite some years the 'current' context release is the one that ends up on texlive. The rest of the year we talk about betas and very rarely an alpha release. This distinction no longer makes sense. From now on there will be no alpha, beta or current (with latest begin the most recent of the three, when present): we only will have latest. Most users follow the latest anyway and keeping a copy of some tree is cheap. There will of course be the yearly tex live snapshots and these will have the year attached to them. So, effectively nothing changes, apart from the fact that we no longer use the labels (and distinction on the website). I like this change. A more fundamental distinction is between the versions: pdftex|xetex : mkii (probaly not used that much any longer) luatex|luajittex : mkiv (also the test for luatex dev) luametatex : lmtx (the (upcoming) real deal) Mojca and I are diuscussing / working on an upgrade of the context garden installations and repositories but more about that later, Will lmtx be available on the next texlive? Probably not, LuaMetaTeX sources are not public yet, so TeX Live can't build it and I don't think they are going to just pull binaries into the tree. They are also very cautious with licensing, so unless something is truly open source they won't pull it (e.g. https://ctan.org/pkg/pgf-pie). the original idea was to have it ready (source code and binaries and so) but tl is already too far into freezing code etc so it would not be integrated anyway (testing, installation etc) and therefore our schedule could be delayed and we now take our time to properly organize the new infrastructure on the garden as well as make sure it compiles nicely on all platforms that we want (using the buildbot infrastructure) which in turn triggers other things regarding luametatex being open source .. it will (as already announced) end up as part of the distribution but i don't want to push all that intermediate stuff in there (we have some quality standards, whatever one might think of that) and we're not in that hurry anyway so, tex live will ship the luatex/mkiv combination and mojca, alan and i i will think of a good moment to release the rest (and maybe next year we will make lmtx the default for tex live .. who knows; there is no reason to complicate installation by adding choices) 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] beta vs current
On 1/31/20 8:37 AM, Aditya Mahajan wrote: > On Thu, 30 Jan 2020, Hans Hagen wrote: > >> Hi, >> >> Already for quite some years the 'current' context release is the one >> that ends up on texlive. The rest of the year we talk about betas and >> very rarely an alpha release. This distinction no longer makes sense. >> >> From now on there will be no alpha, beta or current (with latest begin >> the most recent of the three, when present): we only will have latest. >> Most users follow the latest anyway and keeping a copy of some tree is >> cheap. >> >> There will of course be the yearly tex live snapshots and these will >> have the year attached to them. >> >> So, effectively nothing changes, apart from the fact that we no longer >> use the labels (and distinction on the website). > > I like this change. > >> A more fundamental distinction is between the versions: >> >> pdftex|xetex : mkii (probaly not used that much any longer) >> luatex|luajittex : mkiv (also the test for luatex dev) >> luametatex : lmtx (the (upcoming) real deal) >> >> Mojca and I are diuscussing / working on an upgrade of the context >> garden installations and repositories but more about that later, > > Will lmtx be available on the next texlive? Probably not, LuaMetaTeX sources are not public yet, so TeX Live can't build it and I don't think they are going to just pull binaries into the tree. They are also very cautious with licensing, so unless something is truly open source they won't pull it (e.g. https://ctan.org/pkg/pgf-pie). Cheers, Henri > 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 > ___ > ___ 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] beta vs current
On Thu, 30 Jan 2020, Hans Hagen wrote: Hi, Already for quite some years the 'current' context release is the one that ends up on texlive. The rest of the year we talk about betas and very rarely an alpha release. This distinction no longer makes sense. From now on there will be no alpha, beta or current (with latest begin the most recent of the three, when present): we only will have latest. Most users follow the latest anyway and keeping a copy of some tree is cheap. There will of course be the yearly tex live snapshots and these will have the year attached to them. So, effectively nothing changes, apart from the fact that we no longer use the labels (and distinction on the website). I like this change. A more fundamental distinction is between the versions: pdftex|xetex : mkii (probaly not used that much any longer) luatex|luajittex : mkiv (also the test for luatex dev) luametatex : lmtx (the (upcoming) real deal) Mojca and I are diuscussing / working on an upgrade of the context garden installations and repositories but more about that later, Will lmtx be available on the next texlive? 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 ___
[NTG-context] beta vs current
Hi, Already for quite some years the 'current' context release is the one that ends up on texlive. The rest of the year we talk about betas and very rarely an alpha release. This distinction no longer makes sense. From now on there will be no alpha, beta or current (with latest begin the most recent of the three, when present): we only will have latest. Most users follow the latest anyway and keeping a copy of some tree is cheap. There will of course be the yearly tex live snapshots and these will have the year attached to them. So, effectively nothing changes, apart from the fact that we no longer use the labels (and distinction on the website). A more fundamental distinction is between the versions: pdftex|xetex : mkii (probaly not used that much any longer) luatex|luajittex : mkiv (also the test for luatex dev) luametatex : lmtx (the (upcoming) real deal) Mojca and I are diuscussing / working on an upgrade of the context garden installations and repositories but more about that later, 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] Loading OTF fonts?
PATH=$PATH:/Users/adeimantos/Documents/context/tex/texmf-osx-64/bin (Be aware to edit the good path to/tex/texmf-Linux64/bin); Then : context --generate Then again : context --make At last , one loads fonts through : mtxrun --script fonts --reload. Don’t forget to inform CtXt about fonts files : export OSFONTDIR=~/.fonts:/usr/share/fonts:/usr/share/texmf/fonts/opentype/ > Le 12 sept. 2019 à 13:11, Jon Wong a écrit : > > Hi all, > > Oops. I think I’m failing at understanding font lookup folder. Maybe I need > pointers on OSFONTDIR? > > Specifying the full path works. > > Regards > Jon > > >> On Sep 12, 2019, at 6:42 PM, Jon Wong wrote: >> >> Hi all, >> >> I tried following this tex.sx answer: >> https://tex.stackexchange.com/questions/453143/noto-cjk-font-not-usable-with-context >> >> Can someone give me an explanation of what I did wrong? Hit me with all the >> technical concepts. I’m competent with fontspec on XeTeX. >> >> Step 1: Copy NotoSerifCJKsc-Regular.otf to ~/context/tex/texmf-local/fonts >> >> Step 2: Run `mtxrun --script font --convert NotoSerifCJKsc-Regular.otf' >> >> Step 3: Run `mtxrun —script fonts --reload’ >> >> Step 4: Run `context test.tex’ >> >> The error: >> >> fonts > defining > unknown font 'NotoSerifCJKsc-Regular', loading >> aborted >> >> Regards >> Jon >> > > ___ > 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 > ___ ___ 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] Loading OTF fonts?
Hi all, Oops. I think I’m failing at understanding font lookup folder. Maybe I need pointers on OSFONTDIR? Specifying the full path works. Regards Jon > On Sep 12, 2019, at 6:42 PM, Jon Wong wrote: > > Hi all, > > I tried following this tex.sx answer: > https://tex.stackexchange.com/questions/453143/noto-cjk-font-not-usable-with-context > > <https://tex.stackexchange.com/questions/453143/noto-cjk-font-not-usable-with-context> > > Can someone give me an explanation of what I did wrong? Hit me with all the > technical concepts. I’m competent with fontspec on XeTeX. > > Step 1: Copy NotoSerifCJKsc-Regular.otf to ~/context/tex/texmf-local/fonts > > Step 2: Run `mtxrun --script font --convert NotoSerifCJKsc-Regular.otf' > > Step 3: Run `mtxrun —script fonts --reload’ > > Step 4: Run `context test.tex’ > > The error: > > fonts > defining > unknown font 'NotoSerifCJKsc-Regular', loading > aborted > > Regards > Jon > ___ 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] Loading OTF fonts?
Hi all, I tried following this tex.sx answer: https://tex.stackexchange.com/questions/453143/noto-cjk-font-not-usable-with-context <https://tex.stackexchange.com/questions/453143/noto-cjk-font-not-usable-with-context> Can someone give me an explanation of what I did wrong? Hit me with all the technical concepts. I’m competent with fontspec on XeTeX. Step 1: Copy NotoSerifCJKsc-Regular.otf to ~/context/tex/texmf-local/fonts Step 2: Run `mtxrun --script font --convert NotoSerifCJKsc-Regular.otf' Step 3: Run `mtxrun —script fonts --reload’ Step 4: Run `context test.tex’ The error: fonts > defining > unknown font 'NotoSerifCJKsc-Regular', loading aborted Regards Jon ___ 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] texexec is deprecated?
On Mon, 12 Aug 2019 at 13:42, Jon Wong wrote: > > I was able to use `context’ but not `texexec’. The latter (`texexec —pdf > test.tex’) tells me that some format file (`cont-en.fmt’) can’t be found. > > Is `texexec’ obsolete? texexec is only for Mark II (8-bit pdfTeX, XeTeX) which has been frozen for years now. lmtx is only for Mark >= IV (new version of LuaTeX), so texexec no longer makes sense there and anything needed to run it is also missing. Support is only provided for Mark IV and later. Mojca ___ 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] mkii to mkiv - what an ancient user needs to know
Thanks Hans, that's good to know. I was seeing issues which seemed to be related to setupheader statements using command=, which are in heavy use in our system because we use this to externalise styles. But it could easily have been something font-related left in some of the commands. I will work on a minimal example over the next few days and - if I don't solve it myself in the process - I'll post it. Thanks again, Duncan On Wed, 12 Jun 2019 at 08:07, Hans Hagen wrote: > On 6/12/2019 5:22 AM, Duncan Hothersall wrote: > > Hi all. > > > > Long-time user but haven't posted in a long while... > > ** > > > > After many happy years of running a mkii set up I am finally facing the > > fact that time has moved on and upgrading to mkiv. > > > > I understand the biggest change needed to my sources is in the fonts > > handling, but I am getting a few other problems with things like > > chapter/sectioning setups that I can't see mentioned in > > https://www.contextgarden.net/MkIV_Differences > > > > I was wondering if there exists a comprehensive "what you have to change > > in your sources to move from mkii to mkiv" document anywhere or, failing > > that, if anyone can offer guidance on what has changed in the > > chapter/sectioning setups code between the two. > > > > Apologies for not supplying an example of code - I'm not yet at the > > point that that's possible. > > > > Any help much appreciated. And hello to anyone who remembers me from > > fifteen plus years ago! > Do you get errors? There should be no real fundamental differences > betwene mkii and mmkiv wrt the interfac, but because font encodings are > gone and input is utf8 by default that might need to be changed. > Structure has more options. I think the biggest conceptual change in the > setups has been the way footnotes are configured. Of course there are > new commands too. > > So, a small example triggering the issue would help, > > Hans > > ps. Of course the biggest change is that luatex is used instead of > pdftex/xetex. > > - >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] mkii to mkiv - what an ancient user needs to know
On 6/12/2019 5:22 AM, Duncan Hothersall wrote: Hi all. Long-time user but haven't posted in a long while... ** After many happy years of running a mkii set up I am finally facing the fact that time has moved on and upgrading to mkiv. I understand the biggest change needed to my sources is in the fonts handling, but I am getting a few other problems with things like chapter/sectioning setups that I can't see mentioned in https://www.contextgarden.net/MkIV_Differences I was wondering if there exists a comprehensive "what you have to change in your sources to move from mkii to mkiv" document anywhere or, failing that, if anyone can offer guidance on what has changed in the chapter/sectioning setups code between the two. Apologies for not supplying an example of code - I'm not yet at the point that that's possible. Any help much appreciated. And hello to anyone who remembers me from fifteen plus years ago! Do you get errors? There should be no real fundamental differences betwene mkii and mmkiv wrt the interfac, but because font encodings are gone and input is utf8 by default that might need to be changed. Structure has more options. I think the biggest conceptual change in the setups has been the way footnotes are configured. Of course there are new commands too. So, a small example triggering the issue would help, Hans ps. Of course the biggest change is that luatex is used instead of pdftex/xetex. - 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] Fontloader
On 5/25/2019 9:46 PM, Herbert Voss wrote: I had a problem with the fontloader and luatex. I tried to run my test document with context (latest minimal) to compare the output, but I failed. The font LibertinusKeyboard-Regular.otf https://ctan.org/tex-archive/fonts/libertinus-fonts/ uses ligatures especially for the keys above 0x However, I cannot get it run with latest mkiv. It is no problem with xetex. It should print only the five keys and not the ones for every single letter. Herbert \font\keyboard=LibertinusKeyboard-Regular.otf \starttext \keyboard Tab Entf Enter Capslock Windows \stoptext I'll look 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 - ___ 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] Fontloader
I had a problem with the fontloader and luatex. I tried to run my test document with context (latest minimal) to compare the output, but I failed. The font LibertinusKeyboard-Regular.otf https://ctan.org/tex-archive/fonts/libertinus-fonts/ uses ligatures especially for the keys above 0x However, I cannot get it run with latest mkiv. It is no problem with xetex. It should print only the five keys and not the ones for every single letter. Herbert \font\keyboard=LibertinusKeyboard-Regular.otf \starttext \keyboard Tab Entf Enter Capslock Windows \stoptext ___ 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] optional hyphenation patterns in ancient Greek
Dear Pablo, Five months ago I sent you a private email with detailed explanations of how you can achieve that in ConTeXt. I suggest you go through that first before we start talking about a new pattern set. Here is the email, with a few updates (the paragraph quoted at the top is by myself). Date: Thu, 25 Oct 2018 15:05:17 +0200 From: Arthur Reutenauer > In LuaTeX it’s now possible to inject patterns on the fly, at > typesetting time. I admit to not knowing if ConTeXt has a special way to > take advantage of that; it’s a simple command in pure LuaTeX. It would > also be necessary to change a few patterns in the current set, because > they would interact badly with 2γ1μ. More on that tomorrow. OK, so here goes. It is not possible to just use \patterns in the middle of a Mark IV run, because Hans deactivates it (in lang-ini.mkiv) -- clearly a remnant from Mark II, as in pdfTeX and XeTeX it would have resulted in an error; in ConTeXt it just becomes a no-op, which thus shadows LuaTeX’s behaviour that could actually have been useful. The situation in Mark IV is documented in languages-mkiv.pdf which is part of the distribution: Hans rewrote the whole hyphenation routine in Lua in 2014, and users can switch to it with \setuphyphenation[method=traditional] The idea behind the name is apparently that the Lua code mimics the “traditional” way implemented in the TeX engine, and Hans envisages that other methods can be written in the future (but this hasn’t happened yet). The non-Lua method is on by default and can be chosen explicitly with \setuphyphenation[method=default] but it is not possible to inject new patterns that way because of the above. With the Lua method activated, it becomes possible to add patterns on the fly with \registerhyphenationpattern[agr][2γ1μ] Some care should be taken when adding patterns to an existing set, since they can -- and in this case do -- interact with other patterns in the set. Here, I’ve found that this row of patterns (l. 516 of the master file, https://github.com/hyphenation/tex-hyphen/blob/82e5651/hyph-utf8/tex/generic/hyph-utf8/patterns/tex/hyph-grc.tex#L516): 4γμ' 4γμ’ 4γμʼ 4γμ᾽ 4γμ᾿ needs to be overridden with patterns such as γ2μ' γ2μ’ γ2μʼ γ2μ᾽ γ2μ᾿ otherwise the new pattern would allow breaks before the mu. The attached file puts everything together. Best, Arthur \mainlanguage[agr] \definefont[linuxlibertine][name:linlibertineo] \starttext \hsize=1pt \linuxlibertine πρᾶγμα πράγματος \setuphyphenation[method=traditional] \registerhyphenationpattern[agr][2γ1μ γ2μ’] πρᾶγμα πράγματος πραγμ’ ἄτος % Without the second pattern above, we get the incorrect break πραγ-μ’ \stoptext add-patterns-on-the-fly.pdf Description: Adobe PDF document ___ 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] cross references to chapters in a book
On 2/23/19 10:51 AM, Wolfgang Schuster wrote: > [...] >> Is this because I am using MkII with XeTeX? > > Is there a reason why you stick with MkII or XeTeX. Hi Wolfgang, support for Indic languages seems to be the reason to use MkII. Pablo -- http://www.ousia.tk ___ 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] cross references to chapters in a book
Robert Zydenbos schrieb am 22.02.19 um 22:04:
Hmm… although I got your example to work after some tweaking (changing \samplefile to {input and
placing knuth.tex and zapf.tex in the same folder as the test file), I could not reproduce this
with my book. I want to get "chapter 4" but keep getting "chapter 4.0".
You have to create a minimal working example for this because I can’t
tell why you get this output.
Is this because I am using MkII with XeTeX?
Is there a reason why you stick with MkII or XeTeX.
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] cross references to chapters in a book
Still nicer would be the following, but I do not know whether this is
technically possible –
I have the following text:
% start of example: in chapter 4, pp. 38, I have
\subject [wild-stuff]{Wild stuff}
Now comes a lot of weird stuff which I want to refer to later.
…
% end of stuff in one chapter
% in another chapter:
As we already saw in \in{chapter}[wild-stuff], on p.~\at[wild-stuff]
% that was in the other chapter
% end of example
and the result would be: “As we already saw in chapter 4, on p.~38”…
Can such a thing be done?
Robert
> On 22. Feb 2019, at 22:04, Robert Zydenbos wrote:
>
> Hmm… although I got your example to work after some tweaking (changing
> \samplefile to {input and placing knuth.tex and zapf.tex in the same folder
> as the test file), I could not reproduce this with my book. I want to get
> "chapter 4" but keep getting "chapter 4.0".
>
> Is this because I am using MkII with XeTeX?
>
> Robert
>
>> On 22. Feb 2019, at 20:47, Wolfgang Schuster
>> wrote:
>>
>> Robert Zydenbos schrieb am 22.02.19 um 17:14:
>>> Dear wizards of ConTeXt,
>>> In the final stage of completing a book project, I was wondering how to
>>> automatize cross references to chapters. I’ve already figured out how to
>>> refer to pages (using “\at[REFERENCE]”), but how is this done with
>>> chapters? I’m apparently too simple-minded to understand the manual (and I
>>> don’t understand the differences between \reference, \textreference, \in,
>>> \about).
>>
>> When you use \chapter:
>>
>> \starttext
>>
>> \chapter[sec:knuth]{Knuth}
>>
>> \samplefile{knuth}
>>
>> See \in{chapter}[sec:zapf] at \at{page}[sec:zapf].
>>
>> \chapter[sec:zapf]{Zapf}
>>
>> \samplefile{zapf}
>>
>> See \in{chapter}[sec:knuth] at \at{page}[sec:knuth].
>>
>> \stoptext
>
>
___
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] cross references to chapters in a book
Hmm… although I got your example to work after some tweaking (changing
\samplefile to {input and placing knuth.tex and zapf.tex in the same folder as
the test file), I could not reproduce this with my book. I want to get "chapter
4" but keep getting "chapter 4.0".
Is this because I am using MkII with XeTeX?
Robert
> On 22. Feb 2019, at 20:47, Wolfgang Schuster
> wrote:
>
> Robert Zydenbos schrieb am 22.02.19 um 17:14:
>> Dear wizards of ConTeXt,
>> In the final stage of completing a book project, I was wondering how to
>> automatize cross references to chapters. I’ve already figured out how to
>> refer to pages (using “\at[REFERENCE]”), but how is this done with chapters?
>> I’m apparently too simple-minded to understand the manual (and I don’t
>> understand the differences between \reference, \textreference, \in, \about).
>
> When you use \chapter:
>
> \starttext
>
> \chapter[sec:knuth]{Knuth}
>
> \samplefile{knuth}
>
> See \in{chapter}[sec:zapf] at \at{page}[sec:zapf].
>
> \chapter[sec:zapf]{Zapf}
>
> \samplefile{zapf}
>
> See \in{chapter}[sec:knuth] at \at{page}[sec:knuth].
>
> \stoptext
___
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] upcoming betas
Hi We currently have mkii : which uses pdftex/xetex mkiv : which uses lua(jit)tex 1.10 and next year we will also have lmtx : which runs luatex functionally there is no difference between mkiv and lmtx but there are some diferences under the hood. It might also turn out to be a bit more efficient (at least this is what experiments here indicate). The lmtx version is part of a "long term stability" approach and it will probably take some time (and esp testing) to reach that goal. When experiments work out well, the next context meeting will be showtime. One of these days I will ask context dev to test this version because decisions have to be made on how to roll this out. The reason that I mention this development is that in upcoming beta releases one can run into (not that dramatic, easy to fix) issues related to reshuffing some code. I might also involve users who (I know) runs massive amounts of complex documents. Because there is no functional change there are no consequences for daily use of context. However, there can be additional functionality at some point. So, from the users perspective lmtx is just mkiv, but in some places it will identify itself as lmtx (which is handy for checking). 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] improving kannada script
On Fri, Nov 2, 2018 at 1:05 PM Ulrike Fischer wrote: > Am Fri, 2 Nov 2018 12:53:02 +0100 schrieb luigi scarso: > > > >> You could try https://github.com/khaledhosny/luahbtex. Khaled is > >> trying to marry luatex + harfbuzz there > > > sure, it's hardcoded , the final binary is quite heavy ... > > Anyway, I am talking of dll/so plugin and tool, > > it's more on the track of > > https://www.guitex.org/home/images/ArsTeXnica/AT023/luaffi-article.pdf > > Well we (some of the latex team) tried to test this as we have quite > an interest to have an option to use harfbuzz for some fonts but not > every code needed seems to be available publicitly. > > it's complex thing... a binding depends on lua API and the target lib API .. At that time the lua API was still in flux (so a swiglib binding is not so useful) and the luaffi interface non tested (just see the apart on the FFT) . A (stable) luaffi could resolve the luatex side of the binding and being lua code is more easy to adapt if the target API changes. Also if I remember correctly this requires --shell-escape and this > is not really sensible for a user interface. > it's the context ml, enable system commands is default (and we are still here :-) . Anyway ConteXt has a sandbox too. ) But yes, the --safer disable easily exploitable lua commands --[no-]shell-escape disable/enable system commands --shell-restrictedrestrict system commands to a list of commands given in texmf.cnf are part of the picture. Hans and I have to discuss this point. Just to say: on my linux box, xetex from the official deb package has not hb hardcoded: # ldd `which xetex ` linux-vdso.so.1 (0x7ffcb26d2000) libharfbuzz-icu.so.0 => /usr/lib/x86_64-linux-gnu/libharfbuzz-icu.so.0 (0x7f5fe89c5000) libharfbuzz.so.0 => /usr/lib/x86_64-linux-gnu/libharfbuzz.so.0 (0x7f5fe8727000) Even if I set all the paranoia flags, xetex will load these shared objects. With a luaffi things doesn't change, the point is that luatex will load the libs only when/if the user (script) will to do. Of course, the xetex from texlive is statically compiled ... well almost. I still see freetype as shared object. Anyway, as I have said I am now focused on this issue now because I would like to complete/fix it for the next texlive. (to be honest: I think that all these safer shell-* switches are a bit outdated nowadays, but they are there and I don't think they will disappear . ) -- luigi ___ 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] Problem updating 32b version
Hello,
I encountered problem updating ConTeXt.
I'm still using 32b built due to some deps on 3rd party libs (32b, too).
Running 'first-setup.bat' doesn't create 'tex\texmf-mswin\' directory as
usually.
I also modified the first-setup.bat to avoid 64b platform testing - see the
first-setup.txt attached (.bat renamed to .txt due to mail filters).
The 'tex' dir has now:
texmf\
texmf-cache\
texmf-context\
texmf-fonts\
texmf-local\
texmf-modules\
texmf-project\
texmf-win64\
setuptex
setuptex.bat
setuptex.csh
but it used to be:
texmf\
texmf-cache\
texmf-context\
texmf-fonts\
texmf-local\
texmf-modules\
texmf-mswin\ <<<< WAS HERE
texmf-project\
texmf-win64\
setuptex
setuptex.bat
setuptex.csh
The log (first-setup.bat > Upd.log) may be downloaded here (~700 kB):
http://leteckaposta.cz/260806806
Could anyone test obtaining 32b version of ConTeXt?
TIA.
Best regards,
Lukas
--
Ing. Lukáš Procházka | mailto:l...@pontex.cz
Pontex s. r. o. | mailto:pon...@pontex.cz | http://www.pontex.cz | IDDS:
nrpt3sn | IČO: 40763439
Bezová 1658
147 14 Praha 4
Mob.: +420 702 033 396@echo off
setlocal
:fetch
set OWNPATH=%~dp0
set PATH=%OWNPATH%bin;%PATH%
set PLATFORM=mswin
set CYGWIN=nontsec
rem if defined ProgramFiles(x86) (
rem set PLATFORM=win64
rem ) else (
rem if "%PROCESSOR_ARCHITEW6432%"=="AMD64" set PLATFORM=win64
rem )
REM ~ copy /y bin\mtx-update.lua bin\x.lua
rem if "%PLATFORM%" == "win64" goto update-win64
:update-win32
rsync -av --exclude 'rsync.exe' --exclude 'cygwin1.dll' --exclude
'cygiconv-2.dll' rsync://contextgarden.net/minimals/setup/mswin/bin/ bin
goto update
rem :update-win64
rem rsync -av --exclude 'rsync.exe' --exclude 'cygwin1.dll' --exclude
'cygiconv-2.dll' rsync://contextgarden.net/minimals/setup/win64/bin/ bin
rem goto update
:update
REM ~ copy /y bin\x.lua bin\mtx-update.lua
REM --mingw --nofiledatabase --engine=luatex
mtxrun --script ./bin/mtx-update.lua --update --force --make --engine=all
--context=beta --texroot="%OWNPATH%tex" %*
echo.
echo.
echo When you want to use context, you need to initialize the tree with:
echo.
echo %OWNPATH%tex\setuptex.bat %OWNPATH%tex
echo.
echo You can associate this command with a shortcut to the cmd prompt.
echo.
echo Alternatively you can add %OWNPATH%tex\texmf-%PLATFORM%\bin to your PATH
echo variable.
echo.
echo If you run from an editor you can specify the full path to mtxrun.exe:
echo.
echo. %OWNPATH%tex\texmf-%PLATFORM%\bin\mtxrun.exe --autogenerate --script
context --autopdf ...
echo.
:ruby
echo okay > ok.log
ruby -e "File.delete('ok.log')"
if not exist "ok.log" goto end
echo.
echo The distribution has been downloaded but if you want to run pdfTeX and/or
XeTeX you
echo need to run this script with the following directive:
echo.
echo --platform=all
echo.
echo You then also need to install Ruby in order to be able to use texexec.
After
echo installing Ruby you can run this script again which will give you the
formats
echo needed, or you can run:
echo.
echo texexec --make --pdftex
echo texexec --make --xetex
echo.
:okay
del /q ok.log
:end
endlocal
___
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] accessing glyphs in the private area
On 10/2/2018 1:39 PM, Ulrike Fischer wrote: Am Tue, 2 Oct 2018 11:29:46 +0200 schrieb Hans Hagen: Can't you check for a free range instead? sure, but then i also loose some functionality in context (unless i gho for ugly solutions) ... as all glyphs are supposed to have a name access by name is a pretty good alternative Well in my view name and code point are both valid and useful accesses (and I wouldn't trust names too much). Beside this: xetex has (for non-legacy fonts) primitives for all accesses: by char (unicode), slot and name. whatever ... luatex hasn't, here the only (primitive) access are commands like \char which expect a number; the name field of a character is marked as "unused" in the manual. sure, as one can write lua code to provide that feature .. there is no benefit in having that code in the engine (in fact, even more could go) Neither has the generic fontloader imho some suitable primitive command for name access. All the examples in the generic folder uses numbers or direct input: e.g. \Uchar"1D49D or \Uradical "0 "221A one can write these helpers ... i consider those things macro package dependent asd there's often some higher leel interface So it is imho quite natural that people who write code and packages expect the access by \char + code point to work. Why should I bother with a (perhaps font specific) glyph name if I can simply look up a clear code point number in a table? ok, so it depends on the users and viewpoints of macro package writers .. if some extra glyph cannot be given a meaningful name it's probably not worth using anyway And if I got it right you are reserving a specific space to have stable numbers internally, so you are caring about numbers too ;-) symbolic mapping and for text not hard coded (and shared therefore efficient) btu i shifted that space up and hope for the best (for context users that is, as i cannot test a lot now) the main issue is that there are fonts that use private > 0x space I don't know. Wikipedia says that code2000 uses plane 15 but I didn't check. anyway ... i adapted the code to keep the pua intact and also added an option for outside context to keep bogus names ... (context users have several ways to access shapes 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 - ___ 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] accessing glyphs in the private area
Am Tue, 2 Oct 2018 11:29:46 +0200 schrieb Hans Hagen: >> Can't you check for a free range instead? > sure, but then i also loose some functionality in context (unless i gho > for ugly solutions) ... as all glyphs are supposed to have a name access > by name is a pretty good alternative Well in my view name and code point are both valid and useful accesses (and I wouldn't trust names too much). Beside this: xetex has (for non-legacy fonts) primitives for all accesses: by char (unicode), slot and name. luatex hasn't, here the only (primitive) access are commands like \char which expect a number; the name field of a character is marked as "unused" in the manual. Neither has the generic fontloader imho some suitable primitive command for name access. All the examples in the generic folder uses numbers or direct input: e.g. \Uchar"1D49D or \Uradical "0 "221A So it is imho quite natural that people who write code and packages expect the access by \char + code point to work. Why should I bother with a (perhaps font specific) glyph name if I can simply look up a clear code point number in a table? And if I got it right you are reserving a specific space to have stable numbers internally, so you are caring about numbers too ;-) > the main issue is that there are fonts that use private > 0x space I don't know. Wikipedia says that code2000 uses plane 15 but I didn't check. -- Ulrike Fischer http://www.troubleshooting-tex.de/ ___ 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] accessing glyphs in the private area
On 10/2/2018 9:29 AM, Ulrike Fischer wrote: Am Tue, 2 Oct 2018 06:55:02 +0200 schrieb luigi scarso: For what do you reserve the space in the PUA? http://www.pragma-ade.nl/general/manuals/fonts-mkiv.pdf page 32 of the document : As we already mentioned in a previous chapter, in ConTeXt we use Unicode internally. This also means that fonts are organized this way. By default the glyph representation of a Unicode character sits in the same slot in the glyph table. All additional glyphs, like ligatures or alternates are pushed in the private unicode space. This is why in the lists shown in the figures the ligatures have a private Unicode number. Hm. To clarify. In xetex there is clear distinction between the slot and unicode. \XeTeXglyph (slot) and \char (unicode) give different output and \char actively uses the tounicode mapping of the font. \font\test="[lmroman10-regular.otf]" \test \XeTeXglyph"7A \char"7A \bye In luatex \char and \Uchar don't really care about unicode, even if the font has tounicode=1 and tounicode entries, they access the char by the hashed integer number. they access the char in the characters table (where each character has an index field so one can write a simple function that accesses it by index; also, i assume that in xetex \char gives the character as known to tex so if one input non-unicode one gets that) So to get "unicode" the font loader has to sort the glyphs, index unicode glyphs by their unicode code point, and assign "non-unicode" glyphs numbers that don't interfere. Did I got right? indeed, and we use the private space for those with no unicode (which can be a lot, also think for instance of the snippets that make up math extensibles) Then I do understand that you need some free numbers to push glyphes. But I do not understand why to achieve this you remove glyphs from their unicode points. The PUA is not some non-unicode wilderness. The code points there are as valid as in the other code blocks. You wouldn't move away the greek block to get the place, so why do you think it is okay to throw out of the PUA block what SIL and other font designers encoded there? Can't you check for a free range instead? sure, but then i also loose some functionality in context (unless i gho for ugly solutions) ... as all glyphs are supposed to have a name access by name is a pretty good alternative the main issue is that there are fonts that use private > 0x space which then would mean a lot of extra mem for names ... so the question is are there fonts that use that range 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] accessing glyphs in the private area
Am Tue, 2 Oct 2018 06:55:02 +0200 schrieb luigi scarso: >> For what do you reserve the space in the PUA? > http://www.pragma-ade.nl/general/manuals/fonts-mkiv.pdf > page 32 of the document : > As we already mentioned in a previous chapter, in ConTeXt we use > Unicode internally. This also means that fonts are organized this > way. By default the glyph representation of a Unicode character > sits in the same slot in the glyph table. All additional glyphs, > like ligatures or alternates are pushed in the private unicode > space. This is why in the lists shown in the figures the > ligatures have a private Unicode number. Hm. To clarify. In xetex there is clear distinction between the slot and unicode. \XeTeXglyph (slot) and \char (unicode) give different output and \char actively uses the tounicode mapping of the font. \font\test="[lmroman10-regular.otf]" \test \XeTeXglyph"7A \char"7A \bye In luatex \char and \Uchar don't really care about unicode, even if the font has tounicode=1 and tounicode entries, they access the char by the hashed integer number. So to get "unicode" the font loader has to sort the glyphs, index unicode glyphs by their unicode code point, and assign "non-unicode" glyphs numbers that don't interfere. Did I got right? Then I do understand that you need some free numbers to push glyphes. But I do not understand why to achieve this you remove glyphs from their unicode points. The PUA is not some non-unicode wilderness. The code points there are as valid as in the other code blocks. You wouldn't move away the greek block to get the place, so why do you think it is okay to throw out of the PUA block what SIL and other font designers encoded there? Can't you check for a free range instead? -- Ulrike Fischer http://www.troubleshooting-tex.de/ ___ 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] accessing glyphs in the private area
Am Mon, 1 Oct 2018 10:20:07 +0200 schrieb Hans Hagen:
> anyway, the problem, with these private areas is that they are also used
> by the loader (and context) so in order to avoid clashes we move all
> private chars in the font to a dedicated private range
This basically means that for every document and package which uses
the generic fontloader the access to chars in the private area with
\char is now broken in luatex (in xetex it still works fine).
I just got from Claudio Beccari (which seem to have complained to
Luigi) a bug report that the libertine fonts no longer show some of
the keyboard key glyphs due to the same problem.
Can you tell me when this change happend? Perhaps I can build an
older fontloader as a fall back.
> in your case the glyphs have no real useful names so basically i wonder
> what their use it (are they meant for direct access?)
The question on tex.sx claimed that it has the name uniF58C.
I never used the font and don't know how Therese accessed the glyphs
before, but the libertine package has long lists of mappings like
this:
\DeclareTextGlyphY{LinBiolinum_K}{uniE18C}{57740}
How do context users access such glyphs? Why is there no problem?
> you can define
>
> \def\byindex#1{\ctxlua{
> for k, v in pairs(fonts.hashes.identifiers[true].characters) do
> if v.index == #1 then
> tex.print(utf.char(k))
> break
> end
> end
> }}
>
> {\definedfont[Coelacanth] test \byindex{\number"00A33}}
I don't see a use of accessing this glyphs by index - index
positions can change if the font is updated. This can only be a last
resort for glyphs without unicode position.
The only sensible access is by unicode number (which works).
> I can remap those privates to a normalized private name, like P0F581 but
> it depends on how bloated fonts become that have lots of privates.
>
> In that case you can have:
>
> \def\byname#1{\ctxlua{
> for k, v in
> pairs(fonts.hashes.identifiers[true].shared.rawdata.descriptions) do
> if v.name == "#1" then
> tex.print(utf.char(k))
> break
> end
> end
> }}
>
> {\definedfont[Coelacanth] test \byname {P0F581}}
It would at least mean that not the whole characters list must be
searched. And we could create a documented and stable access
command.
--
Ulrike Fischer
http://www.troubleshooting-tex.de/
___
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] open type feature "frac"
On 9/28/2018 10:56 PM, Ulrike Fischer wrote:
Due to a question on tex.sx
(https://tex.stackexchange.com/questions/452969/luatex-fontfeaturefractions-on-turns-first-digits-into-superscripts)
I looked again (see
https://www.mail-archive.com/ntg-context@ntg.nl/msg84822.html) at
the frac feature.
The output is still not really satisfactory. With mode=node numbers
with slash looks okay, but single numbers are rather odd: only the
last digit has the correct size:
\starttext
\font\test={file:linlibertine_r.otf:mode=node;script=latn;language=DFLT;+frac}
\test
787347 125
it all depends on the font and lookups i guess
the logic can be a combination of:
1 - replace digit when followed by digit or slash
2 - replace digit when preceded by slash
3 - replace digit when preceded by fract digit
so a last digit not preceded will not
in fact one can then as well replace all digits non contextual
1/7 1/2 3/4 5/6 7/8 9/10 11/12 31415/27182 1000/100
\font\test={file:linlibertine_r.otf:mode=base;script=latn;language=DFLT;+frac}
\test
787347 125
1/7 1/2 3/4 5/6 7/8 9/10 11/12 31415/27182 1000/100
forget about base mode ... dependent on how the font does frac single
substitutions will be applied (maybe ligs)
\stoptext
(It could be a font bug, the output with xetex isn't good either).
fonts probably have a limited set of lookups
(the 5 and 7 suggests some inconsistency in the lookups)
i must admit that i've seen so many bad frac implementations that i
never use it (and it's definitely something that should be applied very
selectively, not on a whole text stream)
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
___
[NTG-context] open type feature "frac"
Due to a question on tex.sx
(https://tex.stackexchange.com/questions/452969/luatex-fontfeaturefractions-on-turns-first-digits-into-superscripts)
I looked again (see
https://www.mail-archive.com/ntg-context@ntg.nl/msg84822.html) at
the frac feature.
The output is still not really satisfactory. With mode=node numbers
with slash looks okay, but single numbers are rather odd: only the
last digit has the correct size:
\starttext
\font\test={file:linlibertine_r.otf:mode=node;script=latn;language=DFLT;+frac}
\test
787347 125
1/7 1/2 3/4 5/6 7/8 9/10 11/12 31415/27182 1000/100
\font\test={file:linlibertine_r.otf:mode=base;script=latn;language=DFLT;+frac}
\test
787347 125
1/7 1/2 3/4 5/6 7/8 9/10 11/12 31415/27182 1000/100
\stoptext
(It could be a font bug, the output with xetex isn't good either).
--
Ulrike Fischer
https://www.troubleshooting-tex.de/
___
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] resetting footnote counter
What I've done is the following: I've made a zip archive (see attachment) with a few relevant files – the two first files that will be a part of the book: preface.tex and how-to-use.tex, together with an environment file manual-environment-xasia.tex with a lot of settings, and the starting file sample.tex which puts everything together. This does not need odd things like exotic fonts, and it does not contain uncommon tables etc. I've changed the main font to TeX Gyre Termes, which all of us have (so I assume, since it comes with the major TeX distributions), so there should be no problems there either; but if there is an error message, you can comment out line 12 in manual-environment-xasia.tex and de-comment line 13 to turn the font into Times (or you can change the name of the font to anything you have on your computer). Right now I am using an iMac with the latest OS installed. The 'footnotes' will be placed at the end of the chapters (i.e., they will be endnotes). If you run sample.tex through ConTeXt and XeTeX (i.e., MkII) and look at the final page, you will see that the footnote / endnote marker has not been reset. Robert > On 9. Aug 2018, at 16:37, Aditya Mahajan wrote: > > On Thu, 9 Aug 2018, Robert Zydenbos wrote: > >> I have tried ‘\resetcounter [footnote]’ (a suggested solution on that web >> page), but it does not work (at least not in MkII+XeTeX). ‘\setupcounter >> [footnote] [0]’ (also suggested on that web page) is rejected as an error. > > Can you post a minimal example. Because the following works in MKII (counter > reset at each chapter) […] <> ___ 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] resetting footnote counter
You disable the chapter counter with \setuphead [chapter] [incrementnumber=no] which prevents the reset of the footnote counter. Wolfgang Robert Zydenbos schrieb am 09.08.18 um 17:21: What I've done is the following: I've made a zip archive (see attachment) with a few relevant files – the two first files that will be a part of the book: preface.tex and how-to-use.tex, together with an environment file manual-environment-xasia.tex with a lot of settings, and the starting file sample.tex which puts everything together. This does not need odd things like exotic fonts, and it does not contain uncommon tables etc. I've changed the main font to TeX Gyre Termes, which all of us have (so I assume, since it comes with the major TeX distributions), so there should be no problems there either; but if there is an error message, you can comment out line 12 in manual-environment-xasia.tex and de-comment line 13 to turn the font into Times (or you can change the name of the font to anything you have on your computer). Right now I am using an iMac with the latest OS installed. The 'footnotes' will be placed at the end of the chapters (i.e., they will be endnotes). If you run sample.tex through ConTeXt and XeTeX (i.e., MkII) and look at the final page, you will see that the footnote / endnote marker has not been reset. Robert On 9. Aug 2018, at 16:37, Aditya Mahajan wrote: On Thu, 9 Aug 2018, Robert Zydenbos wrote: I have tried ‘\resetcounter [footnote]’ (a suggested solution on that web page), but it does not work (at least not in MkII+XeTeX). ‘\setupcounter [footnote] [0]’ (also suggested on that web page) is rejected as an error. Can you post a minimal example. Because the following works in MKII (counter reset at each chapter) […] ___ 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 ___ ___ 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] resetting footnote counter
Have you tried to use mkiv for your document.
Wolfgang
Robert Zydenbos schrieb am 09.08.18 um 14:49:
tex.stackexchange.com has page titled “How to manually reset the footnote
numbering in ConTeXt?”
(https://tex.stackexchange.com/questions/359702/how-to-manually-reset-the-footnote-numbering-in-context),
where exactly the same question was asked:
---begin quote---
“I have a document with many footnotes, like this:
This is some text\footnote{This is a footnote}.
This is some more text\footnote{This is another footnote}.
This is yet another text\footnote{This is some more footnote text}.
This produces footnotes numbered 1, 2, 3, etc.
I need to manually reset the footnote number back to 1. E.g.:
This is some text\footnote{This is a footnote}.
This is some more text\footnote{This is another footnote}.
\resetfootnote
This is yet another text\footnote{This is some more footnote text}.
This should produce footnotes numbered 1, 2, then 1 again.”)
---end quote---
But no conclusive answer was found. The questioner then said: “I tried changing
way=bypage and way=bysection, but it does not get the correct results, which is
to have the numbers reset each time \placefootnotes is called. As bypage and
bysection both don't do that, I need to be able to manually adjust the
numbering.”
I have tried ‘\resetcounter [footnote]’ (a suggested solution on that web
page), but it does not work (at least not in MkII+XeTeX). ‘\setupcounter
[footnote] [0]’ (also suggested on that web page) is rejected as an error.
Robert
___
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
___
___
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] resetting footnote counter
What I've done is the following: I've made a zip archive (see attachment) with a few relevant files – the two first files that will be a part of the book: preface.tex and how-to-use.tex, together with an environment file manual-environment-xasia.tex with a lot of settings, and the starting file sample.tex which puts everything together. This does not need odd things like exotic fonts, and it does not contain uncommon tables etc. I've changed the main font to TeX Gyre Termes, which all of us have (so I assume, since it comes with the major TeX distributions), so there should be no problems there either; but if there is an error message, you can comment out line 12 in manual-environment-xasia.tex and de-comment line 13 to turn the font into Times (or you can change the name of the font to anything you have on your computer). Right now I am using an iMac with the latest OS installed. The 'footnotes' will be placed at the end of the chapters (i.e., they will be endnotes). If you run sample.tex through ConTeXt and XeTeX (i.e., MkII) and look at the final page, you will see that the footnote / endnote marker has not been reset. Robert > On 9. Aug 2018, at 16:37, Aditya Mahajan wrote: > > On Thu, 9 Aug 2018, Robert Zydenbos wrote: > >> I have tried ‘\resetcounter [footnote]’ (a suggested solution on that web >> page), but it does not work (at least not in MkII+XeTeX). ‘\setupcounter >> [footnote] [0]’ (also suggested on that web page) is rejected as an error. > > Can you post a minimal example. Because the following works in MKII (counter > reset at each chapter) […] <> ___ 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] resetting footnote counter
On Thu, 9 Aug 2018, Robert Zydenbos wrote:
I have tried ‘\resetcounter [footnote]’ (a suggested solution on that
web page), but it does not work (at least not in MkII+XeTeX).
‘\setupcounter [footnote] [0]’ (also suggested on that web page) is
rejected as an error.
Can you post a minimal example. Because the following works in MKII
(counter reset at each chapter)
\setupfootnotes[way=bychapter]
\starttext
\dorecurse{5}
{\chapter{New Chapter}
\dorecurse{5}{\input ward\footnote{A quote by ward}}}
\stoptext
The following also works with the counter reset at each section:
\setupfootnotes[way=bysection]
\starttext
\dorecurse{5}
{\section{New Chapter}
\dorecurse{5}{\input ward\footnote{A quote by ward}}}
\stoptext
and the following works with the footnote reset at each page:
\setupfootnotes[way=bypage]
\starttext
\dorecurse{5}
{\section{New Chapter}
\dorecurse{5}{\input ward\footnote{A quote by ward}}}
\stoptext
All examples were run using:
ConTeXt ver: 2018.04.04 00:51 MKII fmt: 2018.7.3 int: english/english
and the documents were compiled using
texexec --xetex filename
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] resetting footnote counter
tex.stackexchange.com has page titled “How to manually reset the footnote
numbering in ConTeXt?”
(https://tex.stackexchange.com/questions/359702/how-to-manually-reset-the-footnote-numbering-in-context),
where exactly the same question was asked:
---begin quote---
“I have a document with many footnotes, like this:
This is some text\footnote{This is a footnote}.
This is some more text\footnote{This is another footnote}.
This is yet another text\footnote{This is some more footnote text}.
This produces footnotes numbered 1, 2, 3, etc.
I need to manually reset the footnote number back to 1. E.g.:
This is some text\footnote{This is a footnote}.
This is some more text\footnote{This is another footnote}.
\resetfootnote
This is yet another text\footnote{This is some more footnote text}.
This should produce footnotes numbered 1, 2, then 1 again.”)
---end quote---
But no conclusive answer was found. The questioner then said: “I tried changing
way=bypage and way=bysection, but it does not get the correct results, which is
to have the numbers reset each time \placefootnotes is called. As bypage and
bysection both don't do that, I need to be able to manually adjust the
numbering.”
I have tried ‘\resetcounter [footnote]’ (a suggested solution on that web
page), but it does not work (at least not in MkII+XeTeX). ‘\setupcounter
[footnote] [0]’ (also suggested on that web page) is rejected as an error.
Robert
___
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] resetting footnote counter
Pablo's example works well on my machine. So there must be a disturbance at a
different level in my complex text – perhaps in my settings:
\setupnotedefinition [footnote] [location=serried, distance=1em, hang=1em]
or
\setupfootnotes[bodyfont={Mainfont,8pt}, width=\textwidth, frameoffset=1em,
location=none, way=bychapter]
which in all other respects work fine? ('Mainfont' is my own definition, from a
typescript; I also added 'way=bychapter', to no effect.) The only thing that
does not happen is the resetting of the note counter.
If I had a command that simply says "the counter named X (=footnote counter) is
now 0 again", which I could insert at the beginning of every chapter, the
problem would be solved. (Not so elegant, but it would be a solution.)
Robert
> On 8. Aug 2018, at 17:36, Pablo Rodriguez wrote:
>
> On 08/08/2018 05:03 PM, Robert Zydenbos wrote:
>> Sorry, neither of these work (MkII with XeTeX). I get no error
>> messages with Pablo's suggestion, but not the desired result either.
>
> Weird, this works for me (with and without XeTeX):
>
>\setuppapersize[A8]
>\setupnote[footnote][way=bychapter]
>\starttext
>\chapter{Chapter}
>\dorecurse{2}{Text\footnote{Footnote.}}
>\chapter{Chapter}
>\dorecurse{2}{Text\footnote{Footnote.}}
>\stoptext
>
> Pablo
___
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] resetting footnote counter
On 08/08/2018 05:03 PM, Robert Zydenbos wrote:
> Sorry, neither of these work (MkII with XeTeX). I get no error
> messages with Pablo's suggestion, but not the desired result either.
Weird, this works for me (with and without XeTeX):
\setuppapersize[A8]
\setupnote[footnote][way=bychapter]
\starttext
\chapter{Chapter}
\dorecurse{2}{Text\footnote{Footnote.}}
\chapter{Chapter}
\dorecurse{2}{Text\footnote{Footnote.}}
\stoptext
Pablo
--
http://www.ousia.tk
___
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] resetting footnote counter
%\setupnote[footnote][way=bychapter,location=none]
\setupfootnotes[way=bychapter,location=none]
\starttext
\dorecurse{10}
{\expanded{\chapter{Chapter \recurselevel}}
\dorecurse{10}{\input tufte\footnote{\input ward }\par}
\placenotes[footnote]}
\stoptext
Wolfgang
Robert Zydenbos schrieb am 08.08.18 um 17:03:
Sorry, neither of these work (MkII with XeTeX). I get no error messages with
Pablo's suggestion, but not the desired result either.
Perhaps I need a very primitive command that I can insert at the beginning of
every chapter.
Robert
On 8. Aug 2018, at 16:54, Pablo Rodriguez wrote:
On 08/08/2018 03:55 PM, Taco Hoekwater wrote:
On 8 Aug 2018, at 15:33, Robert Zydenbos wrote:
A simple footnote question this time. I would like to print
endnotes at the end of every chapter in my book, and then reset the
footnote ounter so that in the next chapter the first note will be
‘1’ again. I suppose this should be done by means of \setupfootnotes
– but with which parameter?
Like this (and I also agree that footnote/endnote setup is a bit
complicated, but of course the concept is already quite complicated
itself): [...]
Taco,
I’m afraid Robert needs that for MkII (although he didn‘t mention it).
Robert,
your command reads:
\setupfootnotes[way=bychapter]
By default, footnote numbering seems to be reset by part.
Pablo
___
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
___
___
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] resetting footnote counter
Sorry, neither of these work (MkII with XeTeX). I get no error messages with Pablo's suggestion, but not the desired result either. Perhaps I need a very primitive command that I can insert at the beginning of every chapter. Robert > On 8. Aug 2018, at 16:54, Pablo Rodriguez wrote: > > On 08/08/2018 03:55 PM, Taco Hoekwater wrote: >>> On 8 Aug 2018, at 15:33, Robert Zydenbos wrote: >>> >>> A simple footnote question this time. I would like to print >>> endnotes at the end of every chapter in my book, and then reset the >>> footnote ounter so that in the next chapter the first note will be >>> ‘1’ again. I suppose this should be done by means of \setupfootnotes >>> – but with which parameter? >> >> Like this (and I also agree that footnote/endnote setup is a bit >> complicated, but of course the concept is already quite complicated >> itself): [...] > Taco, > > I’m afraid Robert needs that for MkII (although he didn‘t mention it). > > Robert, > > your command reads: > >\setupfootnotes[way=bychapter] > > By default, footnote numbering seems to be reset by part. > > Pablo ___ 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] TeXLive and ConTeXt
Perhaps it is useful that I mention that this is a MkIV problem on my iMac with TeXLive (2018 version). Using MkII, also with XeTeX, everything ran right out of the box. For MkIV, I had to run a program to let LuaTeX find all the fonts, and then it worked. Robert ___ 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] font pathes with colons
On 6/8/2018 11:51 PM, Ulrike Fischer wrote:
I have been playing around with lua fonts and investigating where to
store and how to load them.
The best with luaotfload and latex seems to be currently to get
(with a kpse call) the absolute path and then load with the "xetex"
syntax:
\font\duckchessfont =
[\directlua{tex.sprint(kpse.find_file("luafont-duckchess.lua",
"misc fonts"))}]:mode=node;+liga;+tlig;original=latinmodernsans
This worked but I also saw in the log curious messages
luaotfload | load : font option
"/Users//Documents/Git/lua-font-
pond/texmf/fonts/misc/luafont/luafont-duckchess.lua]:mode=node"
unknown.
I investigated a bit. I'm on windows and imho this looks as if the
syntax parser is splitting after the C: of the drive and putting the
rest in the specification.detail field.
As far as I can see the code which does the splitting is in
font-def.lua and so part of the generic code. Is there anything that
can be done to correct his? Or can one somehow protect the colon
after c: to be interpretated as file-detail separator?
i can support {weird name} but need to check first if it will not
interfere with context (or luatex-plain)
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
___
[NTG-context] font pathes with colons
I have been playing around with lua fonts and investigating where to
store and how to load them.
The best with luaotfload and latex seems to be currently to get
(with a kpse call) the absolute path and then load with the "xetex"
syntax:
\font\duckchessfont =
[\directlua{tex.sprint(kpse.find_file("luafont-duckchess.lua",
"misc fonts"))}]:mode=node;+liga;+tlig;original=latinmodernsans
This worked but I also saw in the log curious messages
luaotfload | load : font option
"/Users//Documents/Git/lua-font-
pond/texmf/fonts/misc/luafont/luafont-duckchess.lua]:mode=node"
unknown.
I investigated a bit. I'm on windows and imho this looks as if the
syntax parser is splitting after the C: of the drive and putting the
rest in the specification.detail field.
As far as I can see the code which does the splitting is in
font-def.lua and so part of the generic code. Is there anything that
can be done to correct his? Or can one somehow protect the colon
after c: to be interpretated as file-detail separator?
--
Ulrike Fischer
http://www.troubleshooting-tex.de/
___
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] Trim blank space of a PDF page
> On 23 May 2018, at 16:44, Alan Braslau <braslau.l...@comcast.net> wrote: > > Do these tools work vectorally, that is identify the drawing extent > and adjust the boundingbox appropriately, or do they (especially gs) > convert to an image and then crop? in pdfcrop, gs computes a boundingbox based on (one assumes) its internal image representation. Then it creates a /CropBox that is then read by the pdfcrop perl script to create occlusion margins for an external image include in a plain tex document. I assume pdftrimwhite does the same. That was what you wanted to know, right? Not the nitty gritty of gs’ internal calculations? Taco > > I use MP to read the pdf and then crop, but to a fixed closed path. > The problem here appears to seek an autocrop. > > Alan > > On Wed, 23 May 2018 12:09:29 +0200 > Hans Hagen <j.ha...@xs4all.nl> wrote: > >> On 5/23/2018 11:25 AM, Taco Hoekwater wrote: >>> >>>> >>>> On 05/23/2018 01:25 AM, Procházka Lukáš Ing. wrote: >>>>> Hello, >>>>> >>>>> just curious - is threre a way how to crop a page of a PDF via >>>>> ConTeXt? >>>>> >>>>> Ideally - to process a single page PDF into another file, with >>>>> the one page cropped... >>>> >>> >>> The ‘pdfcrop’ command from TeXLive can do that for you on the >>> command line. It is based around ghostscript which can >>> automatically find the crop area, then uses pdftex,luatex,or xetex >>> to create a new pdf. >>> >>> It is doable to come up with a solution in ConTeXt if you do not >>> mind specifying the cropbox manually, but automatic cropping is >>> probably too hard for ConTeXt itself (and likely would end up >>> duplicating pdfcrop to some extent). >> there is a script >> >> pdftrimwhite.pl >> >> in the distribution >> >> 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 >> ___ > ___ > 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 Elvenkind BV ___ 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] Trim blank space of a PDF page
Do these tools work vectorally, that is identify the drawing extent and adjust the boundingbox appropriately, or do they (especially gs) convert to an image and then crop? I use MP to read the pdf and then crop, but to a fixed closed path. The problem here appears to seek an autocrop. Alan On Wed, 23 May 2018 12:09:29 +0200 Hans Hagen <j.ha...@xs4all.nl> wrote: > On 5/23/2018 11:25 AM, Taco Hoekwater wrote: > > > >> > >> On 05/23/2018 01:25 AM, Procházka Lukáš Ing. wrote: > >>> Hello, > >>> > >>> just curious - is threre a way how to crop a page of a PDF via > >>> ConTeXt? > >>> > >>> Ideally - to process a single page PDF into another file, with > >>> the one page cropped... > >> > > > > The ‘pdfcrop’ command from TeXLive can do that for you on the > > command line. It is based around ghostscript which can > > automatically find the crop area, then uses pdftex,luatex,or xetex > > to create a new pdf. > > > > It is doable to come up with a solution in ConTeXt if you do not > > mind specifying the cropbox manually, but automatic cropping is > > probably too hard for ConTeXt itself (and likely would end up > > duplicating pdfcrop to some extent). > there is a script > > pdftrimwhite.pl > > in the distribution > > 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 > ___ ___ 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] Trim blank space of a PDF page
On 5/23/2018 11:25 AM, Taco Hoekwater wrote: On 05/23/2018 01:25 AM, Procházka Lukáš Ing. wrote: Hello, just curious - is threre a way how to crop a page of a PDF via ConTeXt? Ideally - to process a single page PDF into another file, with the one page cropped... The ‘pdfcrop’ command from TeXLive can do that for you on the command line. It is based around ghostscript which can automatically find the crop area, then uses pdftex,luatex,or xetex to create a new pdf. It is doable to come up with a solution in ConTeXt if you do not mind specifying the cropbox manually, but automatic cropping is probably too hard for ConTeXt itself (and likely would end up duplicating pdfcrop to some extent). there is a script pdftrimwhite.pl in the distribution 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] Trim blank space of a PDF page
> > On 05/23/2018 01:25 AM, Procházka Lukáš Ing. wrote: >> Hello, >> >> just curious - is threre a way how to crop a page of a PDF via ConTeXt? >> >> Ideally - to process a single page PDF into another file, with the one >> page cropped... > The ‘pdfcrop’ command from TeXLive can do that for you on the command line. It is based around ghostscript which can automatically find the crop area, then uses pdftex,luatex,or xetex to create a new pdf. It is doable to come up with a solution in ConTeXt if you do not mind specifying the cropbox manually, but automatic cropping is probably too hard for ConTeXt itself (and likely would end up duplicating pdfcrop to some extent). Best wishes, Taco ___ 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] using lua fonts
On 5/9/2018 3:02 AM, Henri Menke wrote:
Dear list,
this is a follow-up on Ulrike's post, so I'm just hijacking the thread.
How can I use the Lua fonts in Plain? It works fine if I just remove
ConTeXt-specific actualtext bits but as soon as I add features to the
font, the name resolution fails with something like
! Font
\mainfont=file:fonts-demo-rule.lua:original=file:texgyrepagella-regular.
otf not loadable: metric data not found or bad.
MWE is below as always.
(1) This lua font stuff was mostly written for demonstration purposes so
anything done like should really use the mechanisms available in the
macro package used
(2) If you use plain and want to play with the font interface you can
better use the plain code that comes with context because that is what I
can run here (this plain version has always been present btw).
(3) Examples coming from the font manual can use feaures only present in
context (for instance because it uses other code present in context or
because i didn't bother to make in generic).
(4) File lookup is macro package specific.
So, say that you have:
\font\mainfont="file:fonts-demo-rule.lua":original=texgyrepagellaregular;
\mainfont
This code is stored in fonts-demo-rule.lua and we can load that font in
the usual way, by specifying a filename.
\bye
and then in that lua file
if detail then
name = name .. ":" .. detail
end
watch how i replaced the * by : because only context has the * syntax
while you use/want the xetex syntax
mtxrun --script plain yourtexfile
should work gven that you made a format with
mtxrun --script plain --make
(mtxrun --script font --reload --simple will make a plain database if
needed)
It uses luatex-plain that ships with context as format (there's also a
luatex-test file that shows some font stuff).
Fwiw, the latest version also supports font effects at the font level
but one needs luatex 1.08 (which is the current garden version).
Cheers, Henri
--- test.tex ---
\input luaotfload.sty
\font\mainfont="file:fonts-demo-rule.lua":original=file:texgyrepagella-regular.otf
\mainfont
This code is stored in fonts-demo-rule.lua and we can load that font in
the usual way,
by specifying a filename.
\bye
--- fonts-demo-rule.lua ---
return function(specification)
local features = specification.features.normal
local name = features.original or "dejavu-serif"
local option = features.option -- we only support "line"
local size = specification.size -- always set
local detail = specification.detail -- e.g. default
if detail then
name = name .. "*" .. detail
end
local f, id = fonts.constructors.readanddefine(name,size)
if f then
f.properties.name = specification.name
f.properties.virtualized = true
f.fonts = {
{ id = id },
}
for s in string.gmatch("aeuioy",".") do
local n = utf.byte(s)
local c = f.characters[n]
if c then
local w = c.width or 0
local h = c.height or 0
local d = c.depth or 0
if option == "line" then
f.characters[n].commands = {
{ "rule", option == "line" and size/10, w },
}
else
f.characters[n].commands = {
{ "down", d },
{ "rule", h + d, w },
}
end
else
-- probably a real bad font
end
end
end
return f
end
On 04/05/18 06:26, Ulrike Fischer wrote:
I'm trying to run one of the examples of fonts-mkiv.pdf
I copied the code from 4.5 Lua fonts to a file
"fonts-demo-rule.lua". This lua file is in the same directory as my
test file.
Then I tried
\definefont
[MyRuleFont]
[file:fonts-demo-rule.lua*default sa 1]
\starttext
{\MyRuleFont So when we use it we get text }
\stoptext
but I get in the log
fonts > defining > forced type 'lua' of 'fonts-demo-rule' not found
fonts > defining > font with asked name 'fonts-demo-rule' is not
found using lookup 'file'
fonts > defining > unknown font 'fonts-demo-rule', loading aborted
fonts > defining > unable to define 'fonts-demo-rule.lua' as
'MyRuleFont--0'
The file itself is found (I can see its path later on). What is
going on here?
___
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-conte
Re: [NTG-context] ConTeXt Sources (MkII)
> On 18. Apr 2018, at 14:04, Hans Hagen <j.ha...@xs4all.nl> wrote: > > On 4/18/2018 9:39 AM, Robert Zydenbos wrote: >>> On 18. Apr 2018, at 09:35, luigi scarso <luigi.sca...@gmail.com> wrote: >>> >>> Do you really need mkii ? >> I'm afraid so. I need XeTeX for its support of Indic fonts. And for my >> purposes MkII is already very, very nice. > the other languages in indic will probably be supported in a couple of weeks > (basics are there but a bit of extra code is needed) YAY! Cool! ConTeXt MkIV / LuaTeX makes itself seriously interesting for a sixth of mankind. I'll happily serve as a guinea pig / tester. Robert ___ 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] ConTeXt Sources (MkII)
On 4/18/2018 9:39 AM, Robert Zydenbos wrote: On 18. Apr 2018, at 09:35, luigi scarso <luigi.sca...@gmail.com> wrote: Do you really need mkii ? I'm afraid so. I need XeTeX for its support of Indic fonts. And for my purposes MkII is already very, very nice. the other languages in indic will probably be supported in a couple of weeks (basics are there but a bit of extra code is needed) 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] ConTeXt Sources (MkII)
On Wed, Apr 18, 2018 at 9:39 AM, Robert Zydenbos <cont...@zydenbos.net> wrote: > > > On 18. Apr 2018, at 09:35, luigi scarso <luigi.sca...@gmail.com> wrote: > > > > Do you really need mkii ? > > I'm afraid so. I need XeTeX for its support of Indic fonts. And for my > purposes MkII is already very, very nice. > hm...ok. The main entry point is mtxrun : $> mtxrun --script So for mkii we have $> mtxrun --script texexec $> mtxrun --script texfont ... For modules $ mtxrun --script modules mtx-modules | ConTeXt Module Documentation Generators 1.00 mtx-modules | mtx-modules | --convert convert source files (tex, mkii, mkiv, mp) to 'ted' files mtx-modules | --process process source files (tex, mkii, mkiv, mp) to 'pdf' files mtx-modules | --prep use original name with suffix 'prep' appended mtx-modules | --direct use old method instead of extra mtx-modules | mtx-modules | mtx-modules | More information about ConTeXt and the tools that come with it can be found at: mtx-modules | mtx-modules | maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context mtx-modules | webpage : http://www.pragma-ade.nl / http://tex.aanhet.net mtx-modules | wiki : http://contextgarden.net -- luigi ___ 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] ConTeXt Sources (MkII)
BTW, I tried – > Luigi <http://wiki.contextgarden.net/User:Luigi.scarso> has converted all the > context sources into pdf. More details are available at > User:Luigi.scarso/modules.pdf > <http://wiki.contextgarden.net/User:Luigi.scarso/modules.pdf> as mentioned on http://wiki.contextgarden.net/Manuals, but the server does not respond. > On 18. Apr 2018, at 09:39, Robert Zydenbos <cont...@zydenbos.net> wrote: > > >> On 18. Apr 2018, at 09:35, luigi scarso <luigi.sca...@gmail.com> wrote: >> >> Do you really need mkii ? > > I'm afraid so. I need XeTeX for its support of Indic fonts. And for my > purposes MkII is already very, very nice. > > Robert ___ 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] ConTeXt Sources (MkII)
> On 18. Apr 2018, at 09:35, luigi scarso <luigi.sca...@gmail.com> wrote: > > Do you really need mkii ? I'm afraid so. I need XeTeX for its support of Indic fonts. And for my purposes MkII is already very, very nice. Robert ___ 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] how to change the colour of the footnote marker
On 4/9/2018 12:18 PM, Robert Zydenbos wrote: On 09.04.2018 09:45, Hans Hagen wrote: On 4/9/2018 12:33 AM, Robert Zydenbos wrote: […] (I need to use Mk II because I need the functionality of XeTeX.) just curious: what do you mis in mkiv / luatex Support for Indic scripts / fonts. (I think we had a little bit of correspondence on this mailing list three or four years ago about this, and we were not able to convert and use the TrueType fonts I required.) Which specific indic scripts? 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] how to change the colour of the footnote marker
On 09.04.2018 09:45, Hans Hagen wrote: On 4/9/2018 12:33 AM, Robert Zydenbos wrote: […] (I need to use Mk II because I need the functionality of XeTeX.) just curious: what do you mis in mkiv / luatex Support for Indic scripts / fonts. (I think we had a little bit of correspondence on this mailing list three or four years ago about this, and we were not able to convert and use the TrueType fonts I required.) Robert ___ 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] how to change the colour of the footnote marker
On 09.04.2018 00:49, Wolfgang Schuster wrote: Mk II does not have setupnotation[footnote] yet, and when I 'translated' it to setupfootnotes (which ordinarily ought to work in Mk II), it unfortunately did not work. (I need to use Mk II because I need the functionality of XeTeX.) 1. setupnotation is the new command name for setupnotedefinition 2. Which language do you use in your document? Kannada. This is one of the world's larger languages, belonging to the Dravidian language family, spoken in the southern Indian state of Karnataka (its capital city Bangalore / Bengaluru is known outside India mainly as the centre of India's IT industry). I am about to finish writing the first comprehensive modern teaching manual of the language for non-Indian learners, and this is the kind of book that one can hardly leave to typesetters. First I was thinking of producing the ready-to-print PDF in XeLaTeX, but… oh, well, we're among ourselves here, so I think I need not go into the details of why I prefer to do it in ConTeXt. :-) Robert -- Prof. Dr. Robert J. Zydenbos Institute of Indology and Tibetology Department of Asian Studies Ludwig-Maximilians-Universität München (University of Munich – LMU) Germany ___ 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] how to change the colour of the footnote marker
On 4/9/2018 12:33 AM, Robert Zydenbos wrote:
Greetings, Tomáš,
On 08.04.2018 17:41, Tomas Hala wrote:
Hi Robert,
I don't understand if you need solution for MkII, or
if you tried something from MkII.
For MkIV you can use this:
defmycmd#1{startcolor[kleur]#1stopcolor}
setupnotation[footnote][numbercommand=mycmd]
(But I don't know whether it will work witk MkII.)
Thank you for the proffered help – but I found a very similar snippet of
code in a message to this list from 2015 and tried it.
Mk II does not have \setupnotation[footnote] yet, and when I
'translated' it to \setupfootnotes (which ordinarily ought to work in Mk
II), it unfortunately did not work. (I need to use Mk II because I need
the functionality of XeTeX.)
just curious: what do you mis in mkiv / luatex
However, Wolfgang gave the solution! I do not know why that is the
solution :-), but it works.
The best,
Robert
--
-
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] how to change the colour of the footnote marker
Robert Zydenbos <mailto:cont...@zydenbos.net>
9. April 2018 um 00:33
Greetings, Tomáš,
On 08.04.2018 17:41, Tomas Hala wrote:
Hi Robert,
I don't understand if you need solution for MkII, or
if you tried something from MkII.
For MkIV you can use this:
defmycmd#1{startcolor[kleur]#1stopcolor}
setupnotation[footnote][numbercommand=mycmd]
(But I don't know whether it will work witk MkII.)
Thank you for the proffered help – but I found a very similar snippet
of code in a message to this list from 2015 and tried it.
Mk II does not have \setupnotation[footnote] yet, and when I
'translated' it to \setupfootnotes (which ordinarily ought to work in
Mk II), it unfortunately did not work. (I need to use Mk II because I
need the functionality of XeTeX.)
1. \setupnotation is the new command name for \setupnotedefinition
2. Which language do you use in your document?
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] how to change the colour of the footnote marker
Greetings, Tomáš,
On 08.04.2018 17:41, Tomas Hala wrote:
Hi Robert,
I don't understand if you need solution for MkII, or
if you tried something from MkII.
For MkIV you can use this:
defmycmd#1{startcolor[kleur]#1stopcolor}
setupnotation[footnote][numbercommand=mycmd]
(But I don't know whether it will work witk MkII.)
Thank you for the proffered help – but I found a very similar snippet of
code in a message to this list from 2015 and tried it.
Mk II does not have \setupnotation[footnote] yet, and when I
'translated' it to \setupfootnotes (which ordinarily ought to work in Mk
II), it unfortunately did not work. (I need to use Mk II because I need
the functionality of XeTeX.)
However, Wolfgang gave the solution! I do not know why that is the
solution :-), but it works.
The best,
Robert
--
Prof. Dr. Robert J. Zydenbos
Institute of Indology and Tibetology
Department of Asian Studies
Ludwig-Maximilians-Universität München (University of Munich – LMU)
Germany
___
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
___
