[NTG-context] Is there a "smart" capitalisation implementation?

[Zhichu via ntg-context]

Hi,

I am going to convince the Board of a journal to consider ConTeXt as an 
additional option.
I want to make a module before I say anything. Right now I have this title 
problem.

The journal requires the titles to be CAPITALISED, except for the acronyms. I'm 
currently
using backticks `...` to wrap it and replace it with \egroup ...\WORD\bgroup{} 
with
lpeg. This kinda works, but that's so ugly. Besides, the actual story is that I 
also want to
add markdown as an option, so the backticks actually have meanings.

I also checked the typo-cap.lua file to get a clue. But I used to use TeX 
exclusively
and I have to admit that it's so overwhelming for a newbie.

I really like the way where bibtex treats words enclosed in curly braces are 
ignored.
Or are there something that's less aggressive than \WORD so the LaTeX trick 
works:
\def\NoCaseChange#1{\noexpand\NoCaseChange{\noexpand#1}}

Best wishes,
ℤhichu ℂhen

___
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] How to place "Content" and other chapter-level titles the same vertical distance from the top?

[Joel via ntg-context]

I created a chapter title style with a large number telling the chapter number, 
and below it the title of the chapter.
It looks like this:
-    1   <--really big chapter 
number=== <-- there is a border created by a background image between 
these
    How to keep  <--chapter title
    fish
This is the article <-- the article begins
about how to keepfish -

\definefontsize[a]%
\definefontsize[b]%
\definefontsize[c]%
\definefontsize[l]%
\setupbodyfontenvironment[default]%
    [%
        a=1.200,
        b=1.440,
        c=1.728,
        l=8.916
    ]%
%

\setuplabeltext[chapter=\strut]
\setuphead[chapter][style=\ssc,placehead=yes,expansion=yes,page=yes,
numbercommand=\groupedcommand{}{\blank[1cm]},
alternative=middle,
numberstyle=ssl,
numbercolor=green,
strut=yes]

\starttext

    \completecontent
    
    \chapter{Test}
        \input knuth

    \chapter{Test}
        \input knuth

\stoptext
The problem I'm facing, is anytime a chapter title is called, such as "Content" 
in complete content, or something in the appendix, such as one of the indexes, 
no number is printed above, so the vertical distance from the top of the page 
to the top of the chapter title changes. I need these to be consistent, as 
there is a background image, with vertical lines.
Basically, if I call \chapter{}, it appears perfectly aligned vertically on the 
page, with no other settings. But when calling \completecontent or a similar 
title that won't get a number, because the number isn't placed, it is 
vertically higher on the page, but I need it to be printed the same height, as 
it it had an invisible number.
I've tried adding strut (the code has it in two places), but don't know if I've 
used it appropriately, and it didn't solve the problem.
--Joel
___
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] 32-bit OpenBSD

[Alain Delmotte via ntg-context]

  
  
Hi!

Le 1/05/2022 à 11:01, Mojca Miklavec
  via ntg-context a écrit :


  Hi,

How long do we want/need to keep running the builders for 32-bit OpenBSD?

It's taking 2 or 3 times longer to build binaries than for the 64-bit
OS (not that this is super relevant since ppc builder is a whole order
of magnitude slower anyway: building TL there takes about 6 hours) and
I suspect that nobody is using those 32-bit binaries anyway.

Mojca

My portable is a 32-bit on which I am running Lubuntu 18.04; but
  i didn't upgrade ConTeXt lmtx for long as, as I did understand,
  there is no more new binaries.
But I can do without ConTeXt on that computer.
Alain



  

___
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] 32-bit OpenBSD

[Damien Thiriet via ntg-context]

Hi Mojca, hi Hans,


OpenBSD 7.1 64-bit binaries works fine, thanks for upgrading ConTeXt to
the new OpenBSD version. I don't use 32-bit version so as far as I am
concerned, there is no need to compile them.
Best regards,

Damien Thiriet 
___
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] blockligatures removing characters

[Ben Moon via ntg-context]

Hi List,

I'm using blockligatures to avoid the 'Th' ligature in some fonts but keep 
others. Recently I've found this removes the 'h' completely, i.e. 'Th' is 
changed to 'T', 'The' becomes 'Te' etc. 

Is there a way to restore the blockligatures functionality? I'm on ConTeXt 
version 2022.05.02 16:19.

Here is a MWE using Almendra (https://fonts.google.com/specimen/Almendra 
)
 from Google Fonts.

```
\starttypescriptcollection[myfont]

\starttypescript[myfont]
\definefontsynonym[Serif][Almendra-Regular][features=default]
\stoptypescript

\starttypescript[myfont]
\definetypeface[\typescriptone][rm][serif][myfont][default][]
\stoptypescript

\stoptypescriptcollection

\blockligatures[Th]

\definefontfeature[default][default][liga=yes]
\definefontfeature[default:nolig][default][liga=no]
\definefontfeature[default:blocklig][default][liga=yes,blockligatures=yes]

\setupbodyfont[myfont]

\starttext
The This These have the Th ligature and others (fi)

\definedfont[Serif*default:nolig]
The This These have no ligatures (not fi)

\definedfont[Serif*default:blocklig]
The This These are missing the `h' (fi)
\stoptext
```

Best,
Ben___
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] Citeproc-lua

[Denis Maier via ntg-context]

> -Ursprüngliche Nachricht-
> Von: Hans Hagen 
> Gesendet: Samstag, 7. Mai 2022 01:15
> An: Maier, Denis Christian (UB) ; ntg-context@ntg.nl
> Betreff: Re: AW: [NTG-context] Citeproc-lua
> 
> On 5/7/2022 12:33 AM, denis.ma...@unibe.ch wrote:
> >> -Ursprüngliche Nachricht-
> >> Von: ntg-context  Im Auftrag von Hans
> >> Hagen via ntg-context
> >> Gesendet: Freitag, 6. Mai 2022 23:45
> >> An: Denis Maier via ntg-context 
> >> Cc: Hans Hagen 
> >> Betreff: Re: [NTG-context] Citeproc-lua
> >>
> >> [...]
> >>
> >> For the record: i don't think you should write something to the tuc
> >> file that doesn't come from context itself because you can mess it up
> >> (also performaance wise).
> >
> > Really? But what about that stuff? Anyway, even better if the data coming
> from context itself can be used.
> 
> A bibliography is just about (cross) referencing data. If that data comes from
> elsewhere it can best kept indepdendent. One can of course store some
> reference but why the data if it is not used in some special way.

I think we're on the same page here. I was just talking about the info about 
which items have been cited, which pages, prefixes, suffixes, etc. All that 
stuff that is basically already there...

> 
> > Of course you could have another file (just like a bib file
> >> is independent). One problem could be that you need to make some
> >> extra installation to make it work as we're not going to add all kind
> >> of code to the distribution (we tend to go smaller) and someone needs
> >> to maintain that moduie then because users depend in it working.
> >>
> >> Did you look into what pandoc provides? It might be easier to take
> >> that output and include it. Some kind of html? That's easy to render.
> >
> > Pandoc can output context as well, so we can just take that.
> 
> Sure, but some parseble format might be better if one wants control over
> rendering. Basically we're talking about some pseudo formatted bibliography
> entry with some unique tag as reference.

I see...

> 
> > Using the whole bibliography might give problems with regards to
> disambiguation.
> 
> In what sense? Aren't the 'tags' or id's unique? 

Tags/Ids are unique, for sure. But, if you render a bibliography based on 
everything in the bib-file, you might end up with 
Doe 2005a
Doe 2005b
etc.
but in the end you'll remove Doe 2005b, so the whole a/b stuff isn't necessary 
anymore.

Anyway, one can
> 
> - let \cite write some refe to soem file
> - that file gets pandoc'd to a bibliography list
> - that then gets included

Yes, looks reasonable.

> 
> if that list is in some parsable format (like html width classes) we can 
> easily pick
> up info (if needed) and do nmore
> 
> > So, that would work a bit like Aditya's filter module:
> > https://github.com/adityam/filter Right?
> 
> sort of
> 
> > Another option would be to just use pandoc's citeproc directly, as
> > described here:
> > https://github.com/jgm/citeproc/blob/master/man/citeproc.1.md
> >
> > We'd have to pass a list of citations as a JSON object to that citeproc and 
> > use
> the results.
> > The results will include citations as well as the bibliography (all as JSON,
> content can be HTML formatted).
> we can handle json indeed, so hwo does such a json look like? can you make an
> example?

There are some examples on this page 
https://github.com/jgm/citeproc/blob/master/man/citeproc.1.md
Does that help or do you need to know more?

Anyway, this adds the citeproc executable as a dependency. Maybe they can make 
that functionality from pandoc proper.

Denis
___
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
___