![](https://secure.gravatar.com/avatar/ecffc5c1eb6692198d091ee98e921822.jpg?s=120&d=mm&r=g)
Dear Hans and Alan, First, thanks for your wonderful work! I followed your instruction to install ConTeXt LMTX. For the record, I wrote what I did. Any comment is welcome to improve my installation. - create directory: ConTeXtLMTX - download install files. - run “sudo sh ./install.sh” - after a long lists, installation is done without errors. The following settings were used: server : lmtx.contextgarden.net,lmtx.pragma-ade.com,lmtx.pragma-ade.nl instance : install-lmtx extras : ownpath : /Users/graph/ConTeXtLTMX platform : osx-64 - I copied my local files from “texmf-local” in ConTeXt MKIV and run mtxrun - Recently, I am using Atom as an editor. I installed “process-pallete” packge and create a command as following: source /Users/graph/ConTeXtLMTX/tex/setuptex; context {filePath} - At the first run, I got "permission denied” message. /Users/graph/ConTeXtLTMX/tex/texmf-osx-64/bin/luametatex: Permission denied - So I change the permission of luametatex as 755. - After that I tested the sample file which is given in the installation.pdf - Also there is no error when I compile my file which is good in ConTeXt MKIV. - However, there is no simpleslide module. Of course, there is no "module/third” folder. Thus I couldn’t compile a file in screen mode. I hope that I have done it right. I have a question. Is it better to use"/Users/graph/ConTeXtLTMX/tex/texmf-osx-64/bin/mtxrun --autogenerate --script context --autopdf …" instead of “context {filePath}"? Thank you for reading. Best regards, Dalyoung
Hi,
We have worked furiously all day kicking-out extra code, and are pleased to present a lean-and-mean version of luatex with your favorite ConTeXt. Same good taste but only half the calories and a new name: luametatex and ConTeXt LMTX. No more Mk-whatever, no more dependencies for we can now stand on our own. Of course, good-old luatex and MkIV (as well as MkII) will continue to coexist and be maintained. However, now you will be able to run ConTeXt lmtx on your smart thermostat or on your refrigerator for the Internet of Things - the dawn of a new era!
Stay tuned,
Alan and Hans
![](https://secure.gravatar.com/avatar/46562c7d27388490d62e8d7a5bc960dd.jpg?s=120&d=mm&r=g)
On 4/2/2019 1:49 PM, Jeong Dal wrote:
Dear Hans and Alan,
First, thanks for your wonderful work! I followed your instruction to install ConTeXt LMTX. For the record, I wrote what I did. Any comment is welcome to improve my installation.
- create directory: ConTeXtLMTX - download install files. - run “sudo sh ./install.sh” - after a long lists, installation is done without errors. The following settings were used: server : lmtx.contextgarden.net http://lmtx.contextgarden.net,lmtx.pragma-ade.com http://lmtx.pragma-ade.com,lmtx.pragma-ade.nl http://lmtx.pragma-ade.nl instance : install-lmtx extras : ownpath : /Users/graph/ConTeXtLTMX platform : osx-64
- I copied my local files from “texmf-local” in ConTeXt MKIV and run mtxrun - Recently, I am using Atom as an editor. I installed “process-pallete” packge and create a command as following: source /Users/graph/ConTeXtLMTX/tex/setuptex; context {filePath} - At the first run, I got "permission denied” message. /Users/graph/ConTeXtLTMX/tex/texmf-osx-64/bin/luametatex: Permission denied - So I change the permission of luametatex as 755.
hm, that should be done by the installer (Alan is on osx so maybe he knows)
- After that I tested the sample file which is given in the installation.pdf - Also there is no error when I compile my file which is good in ConTeXt MKIV. - However, there is no simpleslide module. Of course, there is no "module/third” folder. Thus I couldn’t compile a file in screen mode.
these have to come from the garden (will be done later) ... for the moment, just copy texmf-modules from another installation to the lmtx tex root and regenerate the file database
I hope that I have done it right. I have a question. Is it better to use"/Users/graph/ConTeXtLTMX/tex/texmf-osx-64/bin/mtxrun --autogenerate --script context --autopdf …" instead of “context {filePath}"?
both work but --autogenerate will remake formats etc when needed after an update
Thank you for reading.
Best regards,
Dalyoung
Hi,
We have worked furiously all day kicking-out extra code, and are pleased to present a lean-and-mean version of luatex with your favorite ConTeXt. Same good taste but only half the calories and a new name: luametatex and ConTeXt LMTX. No more Mk-whatever, no more dependencies for we can now stand on our own. Of course, good-old luatex and MkIV (as well as MkII) will continue to coexist and be maintained. However, now you will be able to run ConTeXt lmtx on your smart thermostat or on your refrigerator for the Internet of Things - the dawn of a new era!
Stay tuned,
Alan and Hans
___________________________________________________________________________________ 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 ___________________________________________________________________________________
-- ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------
![](https://secure.gravatar.com/avatar/aaec8862a4c7f861ffc1f105419e1805.jpg?s=120&d=mm&r=g)
There seems to be some subtle differences in the pdf output when comparing the old and new context This is the context input: \usemodule [vim] \setuppapersize [A4] \setuplayout [ backspace=10mm, topspace=25mm, width=190mm, header=0mm, footer=0mm, height=240mm, ] \setupheader [state=empty, no] \setupbodyfontenvironment [default] [em=italic] \definefontfamily [myfamily] [serif] [TeX Gyre Termes] \setupbodyfont [myfamily, 10pt] \definefontsize [e] \definebodyfontenvironment [default] [e=3.5] \starttext \strut\vfill \startalign[center] {\tfe conText is fun} \blank[10mm] {\em ( ijver & vlijt 8+ )} \stopalign \vfill\strut \stoptext this is the old version this is the new output
![](https://secure.gravatar.com/avatar/46562c7d27388490d62e8d7a5bc960dd.jpg?s=120&d=mm&r=g)
On 4/2/2019 2:40 PM, Floris van Manen wrote:
There seems to be some subtle differences in the pdf output when comparing the old and new context
Hm. Apart from a bit more efficient output there should be no real fundamental differences.
This is the context input:
\usemodule [vim] \setuppapersize [A4] \setuplayout [ backspace=10mm, topspace=25mm, width=190mm, header=0mm, footer=0mm, height=240mm, ]
\setupheader [state=empty, no] \setupbodyfontenvironment [default] [em=italic] \definefontfamily [myfamily] [serif] [TeX Gyre Termes] \setupbodyfont [myfamily, 10pt] \definefontsize [e] \definebodyfontenvironment [default] [e=3.5] \starttext \strut\vfill \startalign[center] {\tfe conText is fun} \blank[10mm] {\em ( ijver & vlijt 8+ )}
\stopalign \vfill\strut \stoptext
this is the old version this is the new output With osx preview? How small can you make that test (try removing characters) till it shows up ok.
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 -----------------------------------------------------------------
![](https://secure.gravatar.com/avatar/aaec8862a4c7f861ffc1f105419e1805.jpg?s=120&d=mm&r=g)
With osx preview? How small can you make that test (try removing characters) till it shows up ok.
yes, OSX 10.11.6 preview Most likely an issue with OSX preview. The pdf show correct on Ubuntu .F the error will stay all the way down: \starttext conText \stoptext \starttext conTest \stoptext \starttext conTest 123 \stoptext
![](https://secure.gravatar.com/avatar/46562c7d27388490d62e8d7a5bc960dd.jpg?s=120&d=mm&r=g)
On 4/2/2019 3:12 PM, Floris van Manen wrote:
With osx preview? How small can you make that test (try removing characters) till it shows up ok.
yes, OSX 10.11.6 preview Most likely an issue with OSX preview. The pdf show correct on Ubuntu indeed on preview no x shows up but it does in other viewers
\nopdfcompression \setupbodyfont [termes,10pt] \startTEXpage x \stopTEXpage as acrobat doesn't complain (and it complains pretty fast) i can't do much about 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 -----------------------------------------------------------------
![](https://secure.gravatar.com/avatar/aaec8862a4c7f861ffc1f105419e1805.jpg?s=120&d=mm&r=g)
indeed on preview no x shows up but it does in other viewers
Not just the x. In the second example the s will disappear, be shows up if you add some extra digits, and then dropping the 2 The OSX preview is flaky but i’d assume the output of both context version would be similar (enough) .F
![](https://secure.gravatar.com/avatar/d4bd34a45c928e8356f38323ff84763e.jpg?s=120&d=mm&r=g)
Am Tue, 2 Apr 2019 15:58:18 +0200 schrieb Floris van Manen:
indeed on preview no x shows up but it does in other viewers
Not just the x. In the second example the s will disappear, be shows up if you add some extra digits, and then dropping the 2
I don't have a mac and can't reproduce the problem. But the missing char seems to be always the last one in the beginbfchar/endbfchar list.
The OSX preview is flaky but i’d assume the output of both context version would be similar (enough)
The new context adds new lines inside the beginbfchar/endbfchar block. Perhaps this confuses preview and it drops the last entry. -- Ulrike Fischer http://www.troubleshooting-tex.de/
![](https://secure.gravatar.com/avatar/46562c7d27388490d62e8d7a5bc960dd.jpg?s=120&d=mm&r=g)
On 4/2/2019 4:18 PM, Ulrike Fischer wrote:
Am Tue, 2 Apr 2019 15:58:18 +0200 schrieb Floris van Manen:
indeed on preview no x shows up but it does in other viewers
Not just the x. In the second example the s will disappear, be shows up if you add some extra digits, and then dropping the 2
I don't have a mac and can't reproduce the problem. But the missing char seems to be always the last one in the beginbfchar/endbfchar list.
The OSX preview is flaky but i’d assume the output of both context version would be similar (enough)
The new context adds new lines inside the beginbfchar/endbfchar block. Perhaps this confuses preview and it drops the last entry. Hm, so it has a bad parser then? Could be. I can remove those lines as test.
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 -----------------------------------------------------------------
![](https://secure.gravatar.com/avatar/46562c7d27388490d62e8d7a5bc960dd.jpg?s=120&d=mm&r=g)
On 4/2/2019 4:18 PM, Ulrike Fischer wrote:
Am Tue, 2 Apr 2019 15:58:18 +0200 schrieb Floris van Manen:
indeed on preview no x shows up but it does in other viewers
Not just the x. In the second example the s will disappear, be shows up if you add some extra digits, and then dropping the 2
I don't have a mac and can't reproduce the problem. But the missing char seems to be always the last one in the beginbfchar/endbfchar list.
The OSX preview is flaky but i’d assume the output of both context version would be similar (enough)
The new context adds new lines inside the beginbfchar/endbfchar block. Perhaps this confuses preview and it drops the last entry. it is indeed the last one that is the issue but changing spacing or adding dummies doesn't help
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 -----------------------------------------------------------------
![](https://secure.gravatar.com/avatar/565476157eb3895a9c928ffce26d988d.jpg?s=120&d=mm&r=g)
On 2 Apr 2019, at 17:11, Hans Hagen
wrote: On 4/2/2019 4:18 PM, Ulrike Fischer wrote:
indeed on preview no x shows up but it does in other viewers
Not just the x. In the second example the s will disappear, be shows up if you add some extra digits, and then dropping the 2 I don't have a mac and can't reproduce the problem. But the missing char seems to be always the last one in the beginbfchar/endbfchar
Am Tue, 2 Apr 2019 15:58:18 +0200 schrieb Floris van Manen: list.
The OSX preview is flaky but i’d assume the output of both context version would be similar (enough) The new context adds new lines inside the beginbfchar/endbfchar block. Perhaps this confuses preview and it drops the last entry. it is indeed the last one that is the issue but changing spacing or adding dummies doesn't help
More likely the problem it has is due to the omitted /CIDSet in the font descriptor. The error is in the display engine, not the text extractor (since cut&paste work ok). And that means the problem is almost certainly not the cmap. The only other non-trivial difference I saw in the old vs. new pdf was that no longer present /CIDSet. Unf., generating one in the text editor is bit beyond me-on-the-could mode, so I can not be certain of that although it seems likely (I checked with FF that the two glyphs are indeed in the embedded font subset and in the exact slots the pdf says they have, so that is also unlikely to be the problem.) Best wishes, Taco
![](https://secure.gravatar.com/avatar/aaec8862a4c7f861ffc1f105419e1805.jpg?s=120&d=mm&r=g)
More likely the problem it has is due to the omitted /CIDSet in the font descriptor.
The error is in the display engine, not the text extractor (since cut&paste work ok). And that means the problem is almost certainly not the cmap. The only other non-trivial difference I saw in the old vs. new pdf was that no longer present /CIDSet.
Unf., generating one in the text editor is bit beyond me-on-the-could mode, so I can not be certain of that although it seems likely (I checked with FF that the two glyphs are indeed in the embedded font subset and in the exact slots the pdf says they have, so that is also unlikely to be the problem.)
I’m not familiar with the internals of pdf files. When i use firefox as pdf viewer, the font information seems to go void in the new version (fun1.pdf).
![](https://secure.gravatar.com/avatar/46562c7d27388490d62e8d7a5bc960dd.jpg?s=120&d=mm&r=g)
On 4/2/2019 8:38 PM, Taco Hoekwater wrote:
On 2 Apr 2019, at 17:11, Hans Hagen
wrote: On 4/2/2019 4:18 PM, Ulrike Fischer wrote:
indeed on preview no x shows up but it does in other viewers
Not just the x. In the second example the s will disappear, be shows up if you add some extra digits, and then dropping the 2 I don't have a mac and can't reproduce the problem. But the missing char seems to be always the last one in the beginbfchar/endbfchar
Am Tue, 2 Apr 2019 15:58:18 +0200 schrieb Floris van Manen: list.
The OSX preview is flaky but i’d assume the output of both context version would be similar (enough) The new context adds new lines inside the beginbfchar/endbfchar block. Perhaps this confuses preview and it drops the last entry. it is indeed the last one that is the issue but changing spacing or adding dummies doesn't help
More likely the problem it has is due to the omitted /CIDSet in the font descriptor.
The error is in the display engine, not the text extractor (since cut&paste work ok). And that means the problem is almost certainly not the cmap. The only other non-trivial difference I saw in the old vs. new pdf was that no longer present /CIDSet.
Unf., generating one in the text editor is bit beyond me-on-the-could mode, so I can not be certain of that although it seems likely (I checked with FF that the two glyphs are indeed in the embedded font subset and in the exact slots the pdf says they have, so that is also unlikely to be the problem.)
ok, i'll check that tomorrow ... (cidsets are actually obsolete) 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 -----------------------------------------------------------------
![](https://secure.gravatar.com/avatar/13bc5842f0b785acdb8f02c38b78439d.jpg?s=120&d=mm&r=g)
My two cents:
I don't believe that it is the CIDSet. Both fun.pdf and fun1.pdf have no
CIDSet (which is good).
The (relevant) differences between the two PDFs are:
- Different ToUnicode
- Different embedded font stream
- Minor differences in the font descriptor
It could be the ToUnicode: If preview is not able to parse the last entry
in the ToUnicode table then it may also drop this glyph in its display,
although ToUnicode is only relevant for text extraction.
It could be the font stream: In the CFF font file there is a CharSet table
that maps character-IDs to glyph-IDs. If preview cannot read the last entry
in this table (or the last glyph, glyph nr. 10) then it might drop it.
By bet is on the ToUnicode, because, usually, if viewers fail to read a
font file then they drop the entire font file and not single glyphs.
Anyway, both PDFs seem to be valid. But I wonder if the differences in the
font descriptor are legitimate (especially StemV):
Object 9 <-> 7: Different entry Ascent integer value: 1127 <-> 806 in font
descriptor dictionary.
Object 9 <-> 7: Different entry Descent integer value: -280 <-> -194 in
font descriptor dictionary.
Object 9 <-> 7: Different entry StemV integer value: 91 <-> 0 in font
descriptor dictionary.
Cheers,
Christoph
On Tue, Apr 2, 2019 at 10:16 PM Hans Hagen
On 4/2/2019 8:38 PM, Taco Hoekwater wrote:
On 2 Apr 2019, at 17:11, Hans Hagen
wrote: On 4/2/2019 4:18 PM, Ulrike Fischer wrote:
Am Tue, 2 Apr 2019 15:58:18 +0200 schrieb Floris van Manen:
indeed on preview no x shows up but it does in other viewers
Not just the x. In the second example the s will disappear, be shows up if you add
I don't have a mac and can't reproduce the problem. But the missing char seems to be always the last one in the beginbfchar/endbfchar list.
The OSX preview is flaky but i’d assume the output of both context version would be similar (enough) The new context adds new lines inside the beginbfchar/endbfchar block. Perhaps this confuses preview and it drops the last entry. it is indeed the last one that is the issue but changing spacing or adding dummies doesn't help
More likely the problem it has is due to the omitted /CIDSet in the font descriptor.
The error is in the display engine, not the text extractor (since cut&paste work ok). And that means the problem is almost certainly not the cmap. The only other non-trivial difference I saw in the old vs. new pdf was that no longer present /CIDSet.
Unf., generating one in the text editor is bit beyond me-on-the-could mode, so I can not be certain of that although it seems likely (I checked with FF that
some extra digits, and then dropping the 2 the two glyphs
are indeed in the embedded font subset and in the exact slots the pdf says they have, so that is also unlikely to be the problem.) ok, i'll check that tomorrow ... (cidsets are actually obsolete)
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
___________________________________________________________________________________
![](https://secure.gravatar.com/avatar/46562c7d27388490d62e8d7a5bc960dd.jpg?s=120&d=mm&r=g)
On 4/3/2019 7:58 AM, Christoph Reller wrote:
My two cents:
I don't believe that it is the CIDSet. Both fun.pdf and fun1.pdf have no CIDSet (which is good). The (relevant) differences between the two PDFs are: - Different ToUnicode - Different embedded font stream - Minor differences in the font descriptor It could be the ToUnicode: If preview is not able to parse the last entry in the ToUnicode table then it may also drop this glyph in its display, although ToUnicode is only relevant for text extraction.
indeed and only very few viewers do that right
It could be the font stream: In the CFF font file there is a CharSet table that maps character-IDs to glyph-IDs. If preview cannot read the last entry in this table (or the last glyph, glyph nr. 10) then it might drop it.
coul dbe but acrobat is very picky on that as is ghostscript and they work
By bet is on the ToUnicode, because, usually, if viewers fail to read a font file then they drop the entire font file and not single glyphs.
hm, but i don't think it's different from non lmtx .. i need to check it
Anyway, both PDFs seem to be valid. But I wonder if the differences in the font descriptor are legitimate (especially StemV): Object 9 <-> 7: Different entry Ascent integer value: 1127 <-> 806 in font descriptor dictionary. Object 9 <-> 7: Different entry Descent integer value: -280 <-> -194 in font descriptor dictionary. Object 9 <-> 7: Different entry StemV integer value: 91 <-> 0 in font descriptor dictionary.
yes, but most of these are bogus and heuristically derived (could be the subset or whole font) and quite certainly not used in rendering (positioning happens at the pdf level) we'll see what magic taco has embrained ... he knows apple pdf handling in detail so ...
Cheers, Christoph
On Tue, Apr 2, 2019 at 10:16 PM Hans Hagen
mailto:j.hagen@xs4all.nl> wrote: On 4/2/2019 8:38 PM, Taco Hoekwater wrote: > > >> On 2 Apr 2019, at 17:11, Hans Hagen
mailto:j.hagen@xs4all.nl> wrote: >> >> On 4/2/2019 4:18 PM, Ulrike Fischer wrote: >>> Am Tue, 2 Apr 2019 15:58:18 +0200 schrieb Floris van Manen: >>>>> indeed on preview no x shows up but it does in other viewers >>>>> >>>> >>>> Not just the x. >>>> In the second example the s will disappear, be shows up if you add some extra digits, and then dropping the 2 >>> I don't have a mac and can't reproduce the problem. But the missing >>> char seems to be always the last one in the beginbfchar/endbfchar >>> list. >>>> The OSX preview is flaky but i’d assume the output of both context version would be similar (enough) >>> The new context adds new lines inside the beginbfchar/endbfchar >>> block. Perhaps this confuses preview and it drops the last entry. >> it is indeed the last one that is the issue but changing spacing or adding dummies doesn't help > > More likely the problem it has is due to the omitted /CIDSet in the font descriptor. > > The error is in the display engine, not the text extractor (since cut&paste work ok). > And that means the problem is almost certainly not the cmap. The only other non-trivial > difference I saw in the old vs. new pdf was that no longer present /CIDSet. > > Unf., generating one in the text editor is bit beyond me-on-the-could mode, so I can > not be certain of that although it seems likely (I checked with FF that the two glyphs > are indeed in the embedded font subset and in the exact slots the pdf says they have, so > that is also unlikely to be the problem.) ok, i'll check that tomorrow ... (cidsets are actually obsolete) Hans
----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl http://www.pragma-ade.nl | www.pragma-pod.nl http://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 mailto: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 ___________________________________________________________________________________
-- ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------
![](https://secure.gravatar.com/avatar/46562c7d27388490d62e8d7a5bc960dd.jpg?s=120&d=mm&r=g)
On 4/2/2019 3:58 PM, Floris van Manen wrote:
indeed on preview no x shows up but it does in other viewers
Not just the x. In the second example the s will disappear, be shows up if you add some extra digits, and then dropping the 2
The OSX preview is flaky but i’d assume the output of both context version would be similar (enough) different backend code so there can be differences ... i have no clue what matters in the case of preview
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 -----------------------------------------------------------------
participants (6)
-
Christoph Reller
-
Floris van Manen
-
Hans Hagen
-
Jeong Dal
-
Taco Hoekwater
-
Ulrike Fischer