Re: [NTG-context] update / punctuation / math
Here in Colorado, we need $\widecowboyhat$. Of course, care should be taken so that it typeset properly in right-to-left as well. Alan On Sat, 1 Apr 2023 10:27:41 +0200 Hans Hagen via ntg-context wrote: > Hi, > > There have been some mails about punctuation spacing and a fix was > added to the engine that related to that. As tests showed it to be > okay so we made an update. It took a bit longer than normal because > we were in the middle of some other math stuff: additional fonts and > extensibles. > > Daniel Flipo maintains a few math fonts (like concrete, xcharter, > erewhon, kp, euler) and the last few weeks more extensive support for > extensibles was added and concrete became quite nice too, so these > fonts make a nice benchmark. As they are part of the lmtx install and > we made sure to support them. > > In the process we adapted our 2023 roadmap of which part is attached > (we included an example end then decided to show of concrete). > > When we go through the process of 'upgrading' we noticed some > interesting names for symbols and 'constructs'. Quite some come from > plain and/or amsmath (in the past taco and aditya did some porting to > context) and we're not always sure if something is really used (or > even what it was intended for) so if you notice something weird or > missing, let us know. Examples are welcome too. It might also be that > something can go away because it's obsolete or never needed (so far > we could resist te kick-out-symbole-name temptation when it comes to > symbol names that we think no sane user can remember or imagine to be > there). > > When often add extra tests to the test suite (math subsection). > > Hans & Mikael > > ps. Alan and I are still messing around with some cross referencing. > That code is still experimental and can have issues that we're > looking at but hard to nail down (huge complex cross-referencing > documents). More about that later. > > == > > We added the tex of the pdf below > > == extract from roadmap == > > \usemodule[article-basic,abbreviations-logos] > > \setupbodyfont[concrete] > > \starttext > > \startsubject[title=Math in \CONTEXT\ roadmap] > > \startitemize[n] > > \startitem > After playing with math support for more than a year, we have > come to the > conclusion that it is time to move on. We have already discarded > italic correction and now are replacing rules with extensibles. Much > was already in > place (and applied) but experiences with type one antykwas made > us review > some \OPENTYPE\ fonts. Not using rules makes some of them look > better. The > effect is subtle and probably not \AMS\ compliant, but we think > that it will > work out well for simple math like fractions of decimal numbers. > Consequently, we have added to our shrinking to-do list the > burden to investigate whether we can remove those obsolete code paths > from the engine. > After all, who needs italic correction, who prefers ugly rules > to beautiful > glyphs, and who understands all these font parameters? > Furthermore, after all > these years, we don't expect \OPENTYPE\ font and \UNICODE\ math > technologies > to improve much; we don't know if \MICROSOFT\ is developing > their technology > further at all. Therefore, we are confident that what we are > doing is the way > it should have been done when math was upgraded. Hopefully users > will notice > the improvements. > \stopitem > > \startitem > Math also means physics and units (that topic was brought up > recently on the > list by Gavin). Therefore, because we're in cleanup mode, we > decided to eliminate some more. With \ISO\ now in place for a long > time, we are going to > ignore the existence of the inch as unit from now on. The unit > will probably > remain in the engine for nostalgic reasons, but it will no be > accepted in > MWE. Instead, we will provide some more modern, culturally > correct, kid-friendly units that we will use in examples, manuals and > such. Because > the four-person strong team dealing with this wants to avoid > making mistakes, > we will go through a careful and scientifically sound process of > calibration > first, using a selected tex savvy audience. We expect these new > units to be > stable a month from now. Believe it or not, in the process of > documenting all > this, we found a buglet in the new math dimension spacing, so it > has already > paid off. Expect to hear more in a month or so, and enjoy your > inches as long > as you still can. In case you wonder how this relates to math > other than > mentioned: the math subsystem has 'mu' as adaptive unit, and > that inspired is > to come up with one for text (in addition to two new more or > less fixed units). > \stopitem > > \startitem > The math family model is a fundamental concept in \TEX\
Re: [NTG-context] registered function call [1160]:...live/2023/texmf-dist/tex/context/base/mkiv/l-sandbox.lua:87: cannot open /.: Permission denied - Alpine Linux
On Fri, Mar 31, 2023 at 10:22:49PM +0200, Hans Hagen via ntg-context wrote: > On 3/31/2023 10:08 PM, Carlos via ntg-context wrote: > > > > sure, why should it, you want lucida so better quit with an error than > > > kicking in some font; actually cmr math fonts have been obsoleted for way > > > over a decade by latin modern math fonts in 32 bit font engines > > Font loading and processing time can be mosty neglected so these 16 seconds > come from something else, maybe there are ways to trace file access. Another > possibility is that your fonts are not cached in which case every run will > involve parsing the otf / ttf and producing whatever resources needed > (normally cached). interesting. Earlier as the output was showing > mkiv lua stats > loaded patterns: en::1, load time: 0.000 > mkiv lua stats > loaded fonts: 4 files: lucidabrightregular.otf, > lucidasansregular.otf, latinmodern-math.otf, lmroman10-regular.otf you asked > so why not use lucida math fonts? which is a valid question but nevertheless unsettling in that lmodern-regular may nat have been called out. I fully understand the inclusion of a latinmodern-math in it as a lucidamath was not previously available but I ponder at the idea and involuntary implementation of having lmroman along the pack. Why? If this is TeX doings, or misdoings (depending how one looks at it), it clearly shows to me that TeX also restricts my freedom to use whatever font I may deem necessary. Don't you think? You can probably disagree with me here, or anyone from the TeX community can, but the roman last was imposed deliberately upon. Someoe may also give a lengthy explanation but that would be just hogwash in thee very end . > > > I was actually thinking to ask you about that, and by falling back to cmr > > math font that perhaps would expedite loading time along the way. > > These fonts are small (only huge cjk fonts with tens of thousands of glyphs > or fonts with hundreds of accumulated features might have some impact but > even then not in the final embedding stage). Yeah. I guess. I can also have mkiv lua stats > loaded patterns: en::1, load time: 0.000 mkiv lua stats > loaded fonts: 3 files: lucidabrightmathsymbol.ttf, lucidanewmathitalic.ttf, lucidabrightregular.otf mkiv lua stats > font engine: otf 3.133, afm 1.513, tfm 1.000, 6 instances, 3 shared in backend, 1 common vectors, 2 common hashes, load time 16.723 seconds but that loading time gets back at me as the culprit sweet reminder of not using cmr then. You know the story by now Hans. I can load any font but not speed things up. Not without going through cmr. It is what it is. > > Whan talking fonts, enabling for instance expansion (hz) and protusion might > increase runtime a little. In practice, enabling for instance synctex has a > bigger imnpacts on performance than handling fonts. > 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://bitbucket.org/phg/context-mirror/commits/ > wiki : https://contextgarden.net > ___ -- There's got to be more to life than compile-and-go. ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / https://www.ntg.nl/mailman/listinfo/ntg-context webpage : https://www.pragma-ade.nl / http://context.aanhet.net archive : https://bitbucket.org/phg/context-mirror/commits/ wiki : https://contextgarden.net ___
[NTG-context] natural table oddities
[This mail sat in my drafts folder for days; wanted to research more first, well…] Am 28.03.23 um 02:19 schrieb Bruce Horrocks: If you're asking for comments with a view to making changes then... I can’t make the changes myself, only suggest them to Hans. On 27 Mar 2023, at 15:03, Henning Hraban Ramm via ntg-context wrote: * If I format a column, e.g. \setupTABLE[c][-1][color=red], body and foot are formatted, but not the same column in header. I couldn’t find how to format columns in header. If you disregard the Wiki page instructions to use \bTH...\eTH then you can format the header using: \bTD ... \eTD but I'm not sure what the consequences might be, if any. You lose the default bold heading so maybe that's all /bTH.../eTH is adding? Yes, I also found that out – either I sent an incomplete email, or I forgot to add my later “research”. 樂 TH (table header, not Taco or Tomáš ) adds a separation between header and body cells, but setting up "header" affects both TD and TH within TABLEhead. It would be nice to have a way of specifying the header explicitly. My suggestion would be to have: - \setupTABLE[r][head][...] affect just the header - \setupTABLE[r][next][...] affect the new page header - \setupTABLE[r][first|last|body][...] affect the first, or last, or only the body rows (i.e. not the header or footer) - \setupTABLE[r][foot][...] affect just the footer [r][last] (and [r][-1]) would represent the last body row (but not the footer row if one has been requested). I agree. ## Formatting * maxwidth doesn’t seem to have an effect, neither on the whole table nor on a column. * textwidth works only for the whole table. * width gets stretched if option=stretch; i.e. I can’t fix the width of single cells or columns. For me, \setupTABLE [c] [1] [width=3cm] fixes the width of column 1 and forces long text to wrap. But the width of a column is not fixed if you set option=stretch, then *all* columns are stretched, not only the undefined. Hraban ___ 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] update / punctuation / math
Cute, as always today :-) Willi > On 1 Apr 2023, at 10:27, Hans Hagen via ntg-context > wrote: > > Hi, > > There have been some mails about punctuation spacing and a fix was added to > the engine that related to that. As tests showed it to be okay so we made an > update. It took a bit longer than normal because we were in the middle of > some other math stuff: additional fonts and extensibles. > > Daniel Flipo maintains a few math fonts (like concrete, xcharter, erewhon, > kp, euler) and the last few weeks more extensive support for extensibles was > added and concrete became quite nice too, so these fonts make a nice > benchmark. As they are part of the lmtx install and we made sure to support > them. > > In the process we adapted our 2023 roadmap of which part is attached (we > included an example end then decided to show of concrete). > > When we go through the process of 'upgrading' we noticed some interesting > names for symbols and 'constructs'. Quite some come from plain and/or amsmath > (in the past taco and aditya did some porting to context) and we're not > always sure if something is really used (or even what it was intended for) so > if you notice something weird or missing, let us know. Examples are welcome > too. It might also be that something can go away because it's obsolete or > never needed (so far we could resist te kick-out-symbole-name temptation when > it comes to symbol names that we think no sane user can remember or imagine > to be there). > > When often add extra tests to the test suite (math subsection). > > Hans & Mikael > > ps. Alan and I are still messing around with some cross referencing. That > code is still experimental and can have issues that we're looking at but hard > to nail down (huge complex cross-referencing documents). More about that > later. > > == > > We added the tex of the pdf below > > == extract from roadmap == > > \usemodule[article-basic,abbreviations-logos] > > \setupbodyfont[concrete] > > \starttext > > \startsubject[title=Math in \CONTEXT\ roadmap] > > \startitemize[n] > > \startitem >After playing with math support for more than a year, we have come to the >conclusion that it is time to move on. We have already discarded italic >correction and now are replacing rules with extensibles. Much was already > in >place (and applied) but experiences with type one antykwas made us review >some \OPENTYPE\ fonts. Not using rules makes some of them look better. The >effect is subtle and probably not \AMS\ compliant, but we think that it > will >work out well for simple math like fractions of decimal numbers. >Consequently, we have added to our shrinking to-do list the burden to >investigate whether we can remove those obsolete code paths from the > engine. >After all, who needs italic correction, who prefers ugly rules to beautiful >glyphs, and who understands all these font parameters? Furthermore, after > all >these years, we don't expect \OPENTYPE\ font and \UNICODE\ math > technologies >to improve much; we don't know if \MICROSOFT\ is developing their > technology >further at all. Therefore, we are confident that what we are doing is the > way >it should have been done when math was upgraded. Hopefully users will > notice >the improvements. > \stopitem > > \startitem >Math also means physics and units (that topic was brought up recently on > the >list by Gavin). Therefore, because we're in cleanup mode, we decided to >eliminate some more. With \ISO\ now in place for a long time, we are going > to >ignore the existence of the inch as unit from now on. The unit will > probably >remain in the engine for nostalgic reasons, but it will no be accepted in >MWE. Instead, we will provide some more modern, culturally correct, >kid-friendly units that we will use in examples, manuals and such. Because >the four-person strong team dealing with this wants to avoid making > mistakes, >we will go through a careful and scientifically sound process of > calibration >first, using a selected tex savvy audience. We expect these new units to be >stable a month from now. Believe it or not, in the process of documenting > all >this, we found a buglet in the new math dimension spacing, so it has > already >paid off. Expect to hear more in a month or so, and enjoy your inches as > long >as you still can. In case you wonder how this relates to math other than >mentioned: the math subsystem has 'mu' as adaptive unit, and that inspired > is >to come up with one for text (in addition to two new more or less fixed >units). > \stopitem > > \startitem >The math family model is a fundamental concept in \TEX\ but we think we can >do without. First of all, \OPENTYPE\ math fonts have (design) script and >scriptscript sizes built in, so for that we have
[NTG-context] Cron /var/www/aanhet.net/context/bin/cron/context-mirror
receiving incremental file list ./ ctan.lsr document-2.htm download-1.htm download-2.htm logo-ade.png logo-cts.png logo-pod.png rss.xml show-fil.pdf context/latest/ context/latest/cont-mpd.zip context/latest/cont-ppc.zip context/latest/cont-sci.zip context/latest/cont-tmf.zip context/latest/cont-tst.7z context/latest/cont-tst.tar.xz context/latest/cont-tst.zip sent 101,040 bytes received 22,366,029 bytes 4,084,921.64 bytes/sec total size is 448,196,172 speedup is 19.95 Running archiver: New dir: /var/www/aanhet.net/context//htdocs/archives/context-2023-04-01.11 120337257 /var/www/aanhet.net/context//htdocs/archives/context-2023-04-01.11/latest 126745317 /var/www/aanhet.net/context//htdocs/archives/context-2023-04-01.11/current 247086670 /var/www/aanhet.net/context//htdocs/archives/context-2023-04-01.11 247086670 total ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / https://www.ntg.nl/mailman/listinfo/ntg-context webpage : https://www.pragma-ade.nl / http://context.aanhet.net archive : https://bitbucket.org/phg/context-mirror/commits/ wiki : https://contextgarden.net ___
[NTG-context] update / punctuation / math
Hi, There have been some mails about punctuation spacing and a fix was added to the engine that related to that. As tests showed it to be okay so we made an update. It took a bit longer than normal because we were in the middle of some other math stuff: additional fonts and extensibles. Daniel Flipo maintains a few math fonts (like concrete, xcharter, erewhon, kp, euler) and the last few weeks more extensive support for extensibles was added and concrete became quite nice too, so these fonts make a nice benchmark. As they are part of the lmtx install and we made sure to support them. In the process we adapted our 2023 roadmap of which part is attached (we included an example end then decided to show of concrete). When we go through the process of 'upgrading' we noticed some interesting names for symbols and 'constructs'. Quite some come from plain and/or amsmath (in the past taco and aditya did some porting to context) and we're not always sure if something is really used (or even what it was intended for) so if you notice something weird or missing, let us know. Examples are welcome too. It might also be that something can go away because it's obsolete or never needed (so far we could resist te kick-out-symbole-name temptation when it comes to symbol names that we think no sane user can remember or imagine to be there). When often add extra tests to the test suite (math subsection). Hans & Mikael ps. Alan and I are still messing around with some cross referencing. That code is still experimental and can have issues that we're looking at but hard to nail down (huge complex cross-referencing documents). More about that later. == We added the tex of the pdf below == extract from roadmap == \usemodule[article-basic,abbreviations-logos] \setupbodyfont[concrete] \starttext \startsubject[title=Math in \CONTEXT\ roadmap] \startitemize[n] \startitem After playing with math support for more than a year, we have come to the conclusion that it is time to move on. We have already discarded italic correction and now are replacing rules with extensibles. Much was already in place (and applied) but experiences with type one antykwas made us review some \OPENTYPE\ fonts. Not using rules makes some of them look better. The effect is subtle and probably not \AMS\ compliant, but we think that it will work out well for simple math like fractions of decimal numbers. Consequently, we have added to our shrinking to-do list the burden to investigate whether we can remove those obsolete code paths from the engine. After all, who needs italic correction, who prefers ugly rules to beautiful glyphs, and who understands all these font parameters? Furthermore, after all these years, we don't expect \OPENTYPE\ font and \UNICODE\ math technologies to improve much; we don't know if \MICROSOFT\ is developing their technology further at all. Therefore, we are confident that what we are doing is the way it should have been done when math was upgraded. Hopefully users will notice the improvements. \stopitem \startitem Math also means physics and units (that topic was brought up recently on the list by Gavin). Therefore, because we're in cleanup mode, we decided to eliminate some more. With \ISO\ now in place for a long time, we are going to ignore the existence of the inch as unit from now on. The unit will probably remain in the engine for nostalgic reasons, but it will no be accepted in MWE. Instead, we will provide some more modern, culturally correct, kid-friendly units that we will use in examples, manuals and such. Because the four-person strong team dealing with this wants to avoid making mistakes, we will go through a careful and scientifically sound process of calibration first, using a selected tex savvy audience. We expect these new units to be stable a month from now. Believe it or not, in the process of documenting all this, we found a buglet in the new math dimension spacing, so it has already paid off. Expect to hear more in a month or so, and enjoy your inches as long as you still can. In case you wonder how this relates to math other than mentioned: the math subsystem has 'mu' as adaptive unit, and that inspired is to come up with one for text (in addition to two new more or less fixed units). \stopitem \startitem The math family model is a fundamental concept in \TEX\ but we think we can do without. First of all, \OPENTYPE\ math fonts have (design) script and scriptscript sizes built in, so for that we have one family. Second, only full bold (heavy) makes sense as companion for regular math which is something that in practice we can support otherwise. So, this makes us consider dropping families altogether which then provides (mem) space for even
