Re: [NTG-context] Metafun scaling problem
On Tue, Oct 2, 2018 at 8:19 AM Lutz Haseloff wrote: > On Windows, I got it working again with current Context (20180404) and > current luatex from win32tex > (1.07 development ID 6686) > > On linux-armhf I did a fresh "./first-setup.sh --engine=luatex" and got: > > mtx-context | ConTeXt Process Management 1.02 > mtx-context | > mtx-context | main context file: > /usr/local/context/tex/texmf-context/tex/context/base/mkiv/context.mkiv > mtx-context | current version: 2018.09.30 19:32 > > and: > > This is LuaTeX, Version 1.09.0 (TeX Live 2019/dev) > > The LuaTeX team is Hans Hagen, Hartmut Henkel, Taco Hoekwater, Luigi > Scarso. > > LuaTeX merges and builds upon (parts of) the code from these projects: > > tex : Donald Knuth > etex : Peter Breitenlohner, Phil Taylor and friends > omega : John Plaice and Yannis Haralambous > aleph : Giuseppe Bilotta > pdftex : Han The Thanh and friends > kpathsea : Karl Berry, Olaf Weber and others > lua : Roberto Ierusalimschy, Waldemar Celes and Luiz Henrique de Figueiredo > metapost : John Hobby, Taco Hoekwater, Luigi Scarso, Hans Hagen and friends > pplib : Paweł Jackowski > fontforge : George Williams (partial) > luajit : Mike Pall (used in LuajitTeX) > > Compiled with libpng 1.6.35; using 1.6.35 > Compiled with lua version 5.3.5 > Compiled with mplib version 2.00 > Compiled with zlib 1.2.11; using 1.2.11 > > Development id: 6930 > > No experimental, i think. > right, it's trunk. -- 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] Metafun scaling problem
On Windows, I got it working again with current Context (20180404) and current luatex from win32tex (1.07 development ID 6686) On linux-armhf I did a fresh "./first-setup.sh --engine=luatex" and got: mtx-context | ConTeXt Process Management 1.02 mtx-context | mtx-context | main context file: /usr/local/context/tex/texmf-context/tex/context/base/mkiv/context.mkiv mtx-context | current version: 2018.09.30 19:32 and: This is LuaTeX, Version 1.09.0 (TeX Live 2019/dev) The LuaTeX team is Hans Hagen, Hartmut Henkel, Taco Hoekwater, Luigi Scarso. LuaTeX merges and builds upon (parts of) the code from these projects: tex : Donald Knuth etex : Peter Breitenlohner, Phil Taylor and friends omega : John Plaice and Yannis Haralambous aleph : Giuseppe Bilotta pdftex: Han The Thanh and friends kpathsea : Karl Berry, Olaf Weber and others lua : Roberto Ierusalimschy, Waldemar Celes and Luiz Henrique de Figueiredo metapost : John Hobby, Taco Hoekwater, Luigi Scarso, Hans Hagen and friends pplib : Paweł Jackowski fontforge : George Williams (partial) luajit: Mike Pall (used in LuajitTeX) Compiled with libpng 1.6.35; using 1.6.35 Compiled with lua version 5.3.5 Compiled with mplib version 2.00 Compiled with zlib 1.2.11; using 1.2.11 Development id: 6930 No experimental, i think. Am 2. Oktober 2018 07:12:02 MESZ schrieb luigi scarso : >On Tue, Oct 2, 2018 at 7:03 AM Lutz Haseloff > >wrote: > >> Hi Hans, hi all, >> >> I think, that recent context has a problem with scaling included pdf >files. >> My minimal file: >> >> \startMPpage >> draw externalfigure "cow.pdf" ; >> \stopMPpage >> >> The resulting pdf is, as the original, 97x70.6 mm, all ok. >> >> If I try to scale to the original size, i get arithmetic overflow >error. >> >> \startMPpage >> draw externalfigure "cow.pdf" xscaled 97mm yscaled 70.6mm ; >> \stopMPpage >> >> >> Whe i scale it down, the pdf gets really big. >> >> \startMPpage >> draw externalfigure "cow.pdf" xscaled 27.5mm yscaled 20mm ; >> \stopMPpage >> >> results in a pdf with width of 4.938,8 mm and height of 2.612,3 mm. >> >> I tested with recent context and luatex under windows 64 and >linux-armhf. >> >> which context and luatex version ? Are you using experimental ? >-- >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] accessing glyphs in the private area
Ulrike and Hans wrote > > It is not only that font. Actually the libertine package broke, > > fontawesome broke, and Coelacanth was only used by Thérèse in the > > example as it is free, her real problem was with using Goudy > > fleurons. > in context i strongly advice against using numbers instead of names It's not just explicit numbers via \char, it's character data in documents using specific fonts with documented PUA characters Many fonts use this for assorted reasons https://en.wikipedia.org/wiki/Private_Use_Areas#Vendor_use notably SIL fonts using it for minority languages not in Unicode and Microsoft for all kinds of CJK stuff. Given how many reports are appearing in the few days that this has been exposed to a larger number of uses via LaTeX, use of PUA characters really isn't a rare occurrence at all. If you need to allocate a block for internal use wouldn't it be possible to use one of the high areas Supplementary Private Use Area-A or B (U+F - U+F) (U+10 - U+10) ? The BMP PUA block (U+E000 U+F8FF) just has so many documented uses in existing fonts. David Disclaimer The Numerical Algorithms Group Ltd is a company registered in England and Wales with company number 1249803. The registered office is: Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom. This e-mail has been scanned for all viruses and malware, and may have been automatically archived by Mimecast Ltd, an innovator in Software as a Service (SaaS) for business. ___ 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] Metafun scaling problem
On Tue, Oct 2, 2018 at 7:03 AM Lutz Haseloff wrote: > Hi Hans, hi all, > > I think, that recent context has a problem with scaling included pdf files. > My minimal file: > > \startMPpage > draw externalfigure "cow.pdf" ; > \stopMPpage > > The resulting pdf is, as the original, 97x70.6 mm, all ok. > > If I try to scale to the original size, i get arithmetic overflow error. > > \startMPpage > draw externalfigure "cow.pdf" xscaled 97mm yscaled 70.6mm ; > \stopMPpage > > > Whe i scale it down, the pdf gets really big. > > \startMPpage > draw externalfigure "cow.pdf" xscaled 27.5mm yscaled 20mm ; > \stopMPpage > > results in a pdf with width of 4.938,8 mm and height of 2.612,3 mm. > > I tested with recent context and luatex under windows 64 and linux-armhf. > > which context and luatex version ? Are you using experimental ? -- 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] Metafun scaling problem
Hi Hans, hi all, I think, that recent context has a problem with scaling included pdf files. My minimal file: \startMPpage draw externalfigure "cow.pdf" ; \stopMPpage The resulting pdf is, as the original, 97x70.6 mm, all ok. If I try to scale to the original size, i get arithmetic overflow error. \startMPpage draw externalfigure "cow.pdf" xscaled 97mm yscaled 70.6mm ; \stopMPpage Whe i scale it down, the pdf gets really big. \startMPpage draw externalfigure "cow.pdf" xscaled 27.5mm yscaled 20mm ; \stopMPpage results in a pdf with width of 4.938,8 mm and height of 2.612,3 mm. I tested with recent context and luatex under windows 64 and linux-armhf. Greetings Lutz___ 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 Mon, Oct 1, 2018 at 7:56 PM Ulrike Fischer wrote: > > 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. -- 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] table making ugly column sizes, how to fix?
On Mon, 1 Oct 2018, David Walther wrote: I looked at your example. I ran your example, and on my installation, it has the same problem as I described. I have included a PDF file of my original sample file, and also the PDF generated from your example. What version of ConTeXt are you using? ConTeXt MkIV 2018.09.30 What version are you using? On my installation of context, columns are still coming out "ugly" as you will see in the PDF t1.pdf. Everything seems okay with the latest version of ConTeXt (see attached pdf, obtained from your t1.tex). Aditya t1.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] table making ugly column sizes, how to fix?
I looked at your example. I ran your example, and on my installation, it has
the same problem as I described. I have included a PDF file of my original
sample file, and also the PDF generated from your example. What version of
ConTeXt are you using?
On my installation of context, columns are still coming out "ugly" as you will
see in the PDF t1.pdf. In t2.pdf you'll see the problem shows up in the table
labelled "Good". The "Good" refers to the row in bold, not to the row above
it.
David
On Sun, Sep 30, 2018 at 07:44:12PM -0400, Aditya Mahajan wrote:
On Sat, 29 Sep 2018, David Walther wrote:
Full example at the bottom.
I'm making a table. So far so good.
Every so often I want to make something like a section header.
Regular table rows are like this:
\bTR\bTC \eTC\bTC NightShift \eTC\bTC Tension Lines 146 - 150 \eTC\eTR
For the section headers, I do this, and they look the way I want:
\bTR\bTC 30. \eTC \bTC[nc=2,align=center,style=] \bf{Foo Bar} \eTC\eTR
You can also use
\bTC[nc=2, align=middle, style=bold]
But then the regular lines have ugly line breaks and suddenly the
column size of column 3 is squeezed. This shouldn't be, we have the
whole page to work with.
I don't really see the difference in column sizes between the two
cases. See attached (I simplified and cleaned the example a little)
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
___
t1.tex
Description: TeX document
t2.pdf
Description: Adobe PDF document
t1.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] accessing glyphs in the private area
On 10/1/2018 7:55 PM, Ulrike Fischer wrote:
Am Mon, 1 Oct 2018 19:29:40 +0200 schrieb Hans Hagen:
\DeclareTextGlyphY{LinBiolinum_K}{uniE18C}{57740}
A funny definition ... is that access by name or number?
By number, it uses \char at the end to get the glyph.
Anyway, for generic (so not for context) I can keep these glyphs in the
0xE000-0xEFFF range for now
That would be great. Thanks.
What about the rest and the other PUA's?
U+F000–U+F8FF, U+F–U+D, U+10–U+10FFFD
only U+F000–U+F8FF as i'm not in the mood writing code that skips over
the other ones (we need code points for alternaties and such and i also
need consistent room for virtual chars) ... so, if someone really needs
those slots he/she should remap them somehow
if you really want i can keep their names if there are names (UniXX)
but that would mean way more mem for cjk fonts (then it's all or nothing
for latex, as for plain generic i won't do that anyway)
but i don't expect those areas to be used for useable glyphs
(in fact, i would probably never rely on numbers in such private areas
myself or write some plug into the loader that would remap them to areas
i want them in .. i prefer glyph names)
And when will the change be available? I will have to update
luaotfload.
dunno, when i have some more to upload (sometime this week)
(also the names so larger files ... actually
a mess as that font has Uni and uni so who's to know).
It is not only that font. Actually the libertine package broke,
fontawesome broke, and Coelacanth was only used by Thérèse in the
example as it is free, her real problem was with using Goudy
fleurons.
in context i strongly advice against using numbers instead of names
The private use area is there for every font to use. And quite often
they document this code points and tools like fontforge show them.
I don't think that it is a good idea if an application comes along
and pushes the glyphs from the seats because it wants the space for
itself.
well, we do need space in a valid area
I have no clue if it clashes with some features at some point so
that you can use numbers but probably those features are context
specific anyway.
For what do you reserve the space in the PUA?
all kind of stuff (for instance we have to put substitutes, alternates
etc somewhere; i also have been using it for virtual math fonst for over
a decade now) and i'm definitely not going to move around all kind of
already used slots around now (i might do that some day as i do have
some abstract model but then i also do to need a lot of testing)
i also need the same slots in all fonts for some purposes so i need some
shared private space
(in fact, if i need the higher space glyphs i can always decide to use
names but first i need to run into a real font using these slots in
order to see what is the impact)
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 Mon, 1 Oct 2018 19:29:40 +0200 schrieb Hans Hagen:
>> \DeclareTextGlyphY{LinBiolinum_K}{uniE18C}{57740}
>A funny definition ... is that access by name or number?
By number, it uses \char at the end to get the glyph.
> Anyway, for generic (so not for context) I can keep these glyphs in the
> 0xE000-0xEFFF range for now
That would be great. Thanks.
What about the rest and the other PUA's?
U+F000–U+F8FF, U+F–U+D, U+10–U+10FFFD
And when will the change be available? I will have to update
luaotfload.
> (also the names so larger files ... actually
> a mess as that font has Uni and uni so who's to know).
It is not only that font. Actually the libertine package broke,
fontawesome broke, and Coelacanth was only used by Thérèse in the
example as it is free, her real problem was with using Goudy
fleurons.
The private use area is there for every font to use. And quite often
they document this code points and tools like fontforge show them.
I don't think that it is a good idea if an application comes along
and pushes the glyphs from the seats because it wants the space for
itself.
> I have no clue if it clashes with some features at some point so
> that you can use numbers but probably those features are context
> specific anyway.
For what do you reserve the space in the PUA?
--
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/1/2018 11:42 AM, Ulrike Fischer wrote:
Can you tell me when this change happend? Perhaps I can build an
older fontloader as a fall back.
no, probably a while ago when some other clash in private area use was
solved .. i'm not going to mess with the code now as 0xE000-0xEFFF is
used in context for various things
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}
A funny definition ... is that access by name or number?
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.
So can private unicodes as they are as undefined.
The only sensible access is by unicode number (which works).
Anyway, for generic (so not for context) I can keep these glyphs in the
0xE000-0xEFFF range for now (also the names so larger files ... actually
a mess as that font has Uni and uni so who's to know). I have no clue if
it clashes with some features at some point so that you can use numbers
but probably those features are context specific 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] xtables with lua
On Mon, 1 Oct 2018, Fabrice Couvreur wrote:
Hi,
Thank you Aditya for the link. I knew that with natural tables, but I hoped
it could be done with xtables too.
Almost the same code works with xtables as well (in your example, I don't
know the relationship between the columns)
\starttext
\startluacode
context.startxtable({"align=middle, width=0.8cm"})
context.startxrow()
context.startxcell() context("$(+)$") context.stopxcell()
for y = 1,6 do
context.startxcell() context(y) context.stopxcell()
end
context.stopxrow()
for x = 1,6 do
context.startxrow()
context.startxcell() context(x) context.stopxcell()
for y = 1,6 do
context.startxcell() context(x+y) context.stopxcell()
end
context.stopxrow()
end
context.stopxtable()
\stopluacode
\stoptext
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] xtables with lua
Hi,
Thank you Aditya for the link. I knew that with natural tables, but I hoped
it could be done with xtables too.
Fabrice
Le lun. 1 oct. 2018 à 05:50, Aditya Mahajan a écrit :
> On Mon, 1 Oct 2018, Jeong Dal wrote:
>
> > What do you mean “does not typeset correctly as expected”?
>
> As I said, I fixed the post.
>
> > I copied and tested the last example and got the result without error.
> > One problem is that the vertical alignment is not centered as the
> example of Aditya’s.
> > Would you please tell me what I miss?
>
> The part in the beginning of the post:
>
> \setupTABLE[each][each][width=2em,height=2em,align={middle,middle}]
> \setupTABLE[r][1][background=color,backgroundcolor=gray]
> \setupTABLE[c][1][background=color,backgroundcolor=gray]
>
>
> 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] ntg-context Digest, Vol 172, Issue 2
Dear Aditya, Thank you for the reply. > > As I said, I fixed the post. I see why I have no problem. Thank you for sharing your nice samples. Best regards, Dalyoung___ 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 Mon, Oct 1, 2018 at 11:43 AM Ulrike Fischer wrote: > > I just got from Claudio Beccari (which seem to have complained to > Luigi) > hm, not a complain, a simple "bug report". I always try to answer directly to Claudio when/if I can, but in this case, if I have understood correctly, you are now the/a maintainer of luaotfload, and for sure you can give much better answers than me. -- 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] 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] Which color model shall I use
On 01.10.18 10:11, Henning Hraban Ramm wrote:
> If you can ensure all RGB colors are tagged with the same profiles then it
> should work, as long as you only care about *same* colors and not
> (CMYK-defined) *specific* colors...
>
> Do your SVGs declare their RGB color space?
They start with:
http://www.w3.org/2000/svg";
xmlns:xlink="http://www.w3.org/1999/xlink"; x="0px" y="0px"
viewBox="0 0 170.1 170.1" style="enable-background:new 0 0 170.1
170.1;" xml:space="preserve">
.st0{fill:#99BCDB;}
.st1{fill:#FF;}
.st2{fill:#DD4901;}
.st3{fill:#327AB8;}
.st4{fill:none;}
.st5{clip-path:url(#SVGID_2_);}
.st6{clip-path:url(#SVGID_4_);}
.st7{clip-path:url(#SVGID_6_);}
.st8{clip-path:url(#SVGID_8_);}
When I pick the screen colors with GPick I see that the SVG always stay
the same.
Only my colors I define with \definecolor change in the screen
representation of the PDF file (as I expect).
> Color management *is* complicated.
FullACK
Thanks for your help.
juh
___
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] profile specification '{ISO Coated v2 300% (ECI)} ' not found in 'colorprofiles.xml, colorprofiles.lua'
I get this error when I try to compile a pdf with:
\setupbackend[
format=PDF/X-3:2003,
intent={ISO Coated v2 300\letterpercent\space (ECI)}
]
In log:
backend > profiles > setting format to 'PDF/X-3:2003'
backend > profiles > forcing pdf version 1.4.0, compression
level 3, object compression disabled
colors > defining > supported models: gray 'true', rgb 'true',
cmyk 'true', spot 'true'
transparencies > support > transparency is not supported
viewerlayers> viewerlayers are not supported
backend > xmp > using file
'/home/juh/context/tex/texmf-context/tex/context/base/mkiv/lpdf-pdx.xml'
backend > profiles > profile specification '{ISO Coated v2 300%
(ECI)} ' not found in 'colorprofiles.xml, colorprofiles.lua'
The profile is there:
~/context/tex/texmf-context/colors/icc/profiles$ ls
CoatedFOGRA39.iccProbev1_ICCv2.icc
default_cmyk.icc Probev1_ICCv4.icc
default_gray.icc Probev2_ICCv4.icc
default_rgb.icc ps_cmyk.icc
ecirgb_v2.iccps_gray.icc
ecirgb_v2_iccv4.icc ps_rgb.icc
GRACoL2006_Coated1v2.icc PSRgravureMF.icc
isocoated_v2_300_eci.icc PSR_LWC_PLUS_V2_PT.icc
ISOcoated_v2_300_eci.icc PSR_LWC_STD_V2_PT.icc
isocoated_v2_eci.icc PSR_SC_PLUS_V2_PT.icc
ISOcoated_v2_eci.icc PSR_SC_STD_V2_PT.icc
ISOnewspaper26v4_gr.icc SC_paper_eci.icc
ISOnewspaper26v4.icc sgray.icc
ISOuncoated.icc SNAP2007.icc
ISOuncoatedyellowish.icc srgb.icc
ISOwebcoated.icc srgb_v4_icc_preference.icc
JapanColor2001Coated.icc SWOP2006_Coated3v2.icc
JapanColor2002Newspaper.icc SWOP2006_Coated5v2.icc
JapanWebCoated.icc UncoatedFOGRA29.icc
lab.icc WebCoatedFOGRA28.icc
The profile is also defined in colorporfiles.xml
ISOcoated_v2_300_eci.icc
CMYK
prtr
FOGRA39
ISO Coated v2 300% (ECI)
e14f5db955711d914d877df35ad7a1b5
2400
http://www.color.org
Offset printing, according to ISO
12647-2:2004/Amd 1, OFCOM, paper type 1 or 2 = coated art, 115 g/m2,
tone value increase curves A (CMY) and B (K)
Any hints?
juh
___
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 9/30/2018 10:08 PM, Ulrike Fischer wrote:
The font Coelacanth (on CTAN) has glyphs in the private area.
Between 2/2017 (luaotfload in texlive 2017) and now the storing and
accessing of this glyphs has changed.
In the lua of the font of 2017 I find e.g.
[62860]={
["boundingbox"]=165,
["index"]=2622,
["unicode"]=62860,
["width"]=523,
and the glyph can be accessed with \Uchar62860
In the current lua I now find
[983910]={
["boundingbox"]=195,
["index"]=2622,
["unicode"]=62860,
["width"]=523,
},
and \Uchar62860 not longer works, one has to use \Uchar983910.
Is this change intentional? How is one supposed to access such
chars? The manual says about \Uchar that it "expands to the
associated Unicode character." but this seems no longer to be true.
A context example to test is
\starttext
\font\test={name:Coelacanth:mode=node;script=latn;language=DFLT;+tlig;}
\test
1.: \Uchar62860
2.: \Uchar983910
\stoptext
\Uchar expands to the character in the font, so to whatever sits in that
slot ... in fact, fonts in luatex are not that different from
traditional tex: slot 123 can be anything but it happens that we use
unicode in the fontloader ..
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
in your case the glyphs have no real useful names so basically i wonder
what their use it (are they meant for direct access?)
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 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}}
(btw, This code is not for context users! They have other means; this
is typically stuff that differs per macro package. One might for
instance make a list per font with meaningfull names or so that can be
accessed in a more friendly way.)
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] Which color model shall I use
Am 2018-10-01 um 09:23 schrieb Jan U. Hasecke : > On 30.09.18 17:16, Henning Hraban Ramm wrote: > >> >> Hi juh, >> >> you can define colors in several color models at once; CMYK makes most sense >> for professional printing. >> >> e.g. \definecolor[CompanyBlue][r=0,g=0,b=1,c=1,m=1,y=0,k=0] >> >> and see https://wiki.contextgarden.net/Command/setupcolors >> (I would activate rgb or cmyk colors via modes, if you produce different >> media) > > I don't know how to enable this via modes. \startnotmode[print] \setupcolors[cmyk=no,rgb=yes] \stopnotmode \startmode[print] \setupcolors[cmyk=yes,rgb=no] \stopmode >> CMYK colors in SVG are difficult (I needed them in 2005, nowadays there’s a >> hardly supported standard for icc profile based colors). >> e.g. >> https://stackoverflow.com/questions/3405689/svg-image-with-cmyk-colours-is-it-possible >> https://www.w3.org/TR/SVGColor12/#icc-colors >> >> Something about color profile handling in ConTeXt: >> https://wiki.contextgarden.net/PDFX >> >> Now you must decide if you want to go the PDF/X-1a route (device dependent >> CYMK values) or PDF/X-3 (profiled colors). > > How can I test, what colors are used in the resulting PDF? Currently I > pick the colors with a tool in Gimp to see what colors come up. Can Gimp check the colors in the PDF? (I don’t think so.) I know no other tool for that than Acrobat Pro, but there probably are one or two others; don’t know if there are *free and usable* tools to check on colors/profiles in PDFs... > If I look at the colors this way the RGB values of the included svg are > always the original values defined by the file. All other values are not > the values I defined in the ConTeXt files. > > I think this is due to the cmyk conversion of my screen. > > \setupbackend[ > format=PDF/X-3, > intent=ISO Coated v2 (ECI), > ] > > I tried with this for example. > > Anyway. Wouldn't it be better to produce a RGB-PDF and let the ripper of > the print shop do the conversion? At least I can produce a RGB-PDF where > all colors are defined in the same manner. If you can ensure all RGB colors are tagged with the same profiles then it should work, as long as you only care about *same* colors and not (CMYK-defined) *specific* colors... Do your SVGs declare their RGB color space? Color management *is* complicated. Greetlings, Hraban --- https://www.fiee.net http://wiki.contextgarden.net https://www.dreiviertelhaus.de GPG Key ID 1C9B22FD ___ 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] Which color model shall I use
On 10/1/2018 9:23 AM, Jan U. Hasecke wrote: On 30.09.18 17:16, Henning Hraban Ramm wrote: Hi juh, you can define colors in several color models at once; CMYK makes most sense for professional printing. e.g. \definecolor[CompanyBlue][r=0,g=0,b=1,c=1,m=1,y=0,k=0] and see https://wiki.contextgarden.net/Command/setupcolors (I would activate rgb or cmyk colors via modes, if you produce different media) I don't know how to enable this via modes. \setupcolors[cmyk=yes,rgb=no] etc CMYK colors in SVG are difficult (I needed them in 2005, nowadays there’s a hardly supported standard for icc profile based colors). e.g. https://stackoverflow.com/questions/3405689/svg-image-with-cmyk-colours-is-it-possible https://www.w3.org/TR/SVGColor12/#icc-colors Something about color profile handling in ConTeXt: https://wiki.contextgarden.net/PDFX Now you must decide if you want to go the PDF/X-1a route (device dependent CYMK values) or PDF/X-3 (profiled colors). How can I test, what colors are used in the resulting PDF? Currently I pick the colors with a tool in Gimp to see what colors come up. If I look at the colors this way the RGB values of the included svg are always the original values defined by the file. All other values are not the values I defined in the ConTeXt files. I think this is due to the cmyk conversion of my screen. \setupbackend[ format=PDF/X-3, intent=ISO Coated v2 (ECI), ] I tried with this for example. Anyway. Wouldn't it be better to produce a RGB-PDF and let the ripper of the print shop do the conversion? At least I can produce a RGB-PDF where all colors are defined in the same manner. it depends ... 4 channel cmyk doesn't map entirely on 3 channel rgb and vise versa 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] Which color model shall I use
On 30.09.18 17:16, Henning Hraban Ramm wrote: > > Hi juh, > > you can define colors in several color models at once; CMYK makes most sense > for professional printing. > > e.g. \definecolor[CompanyBlue][r=0,g=0,b=1,c=1,m=1,y=0,k=0] > > and see https://wiki.contextgarden.net/Command/setupcolors > (I would activate rgb or cmyk colors via modes, if you produce different > media) I don't know how to enable this via modes. > CMYK colors in SVG are difficult (I needed them in 2005, nowadays there’s a > hardly supported standard for icc profile based colors). > e.g. > https://stackoverflow.com/questions/3405689/svg-image-with-cmyk-colours-is-it-possible > https://www.w3.org/TR/SVGColor12/#icc-colors > > Something about color profile handling in ConTeXt: > https://wiki.contextgarden.net/PDFX > > Now you must decide if you want to go the PDF/X-1a route (device dependent > CYMK values) or PDF/X-3 (profiled colors). How can I test, what colors are used in the resulting PDF? Currently I pick the colors with a tool in Gimp to see what colors come up. If I look at the colors this way the RGB values of the included svg are always the original values defined by the file. All other values are not the values I defined in the ConTeXt files. I think this is due to the cmyk conversion of my screen. \setupbackend[ format=PDF/X-3, intent=ISO Coated v2 (ECI), ] I tried with this for example. Anyway. Wouldn't it be better to produce a RGB-PDF and let the ripper of the print shop do the conversion? At least I can produce a RGB-PDF where all colors are defined in the same manner. juh ___ 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 ___
