On 18/12/2023 15:13, Ursula Hermann wrote:

...

Dear  List

I was interested how it works.

So I started this example.

\starttext

\usemodule[m-zint]

\barcode[alternative=isbnx, text=9783865419026, width=4cm]

\barcode[alternative=qrcode, text={https://wiki.contextgarden.net}, width=3cm]

\stoptext

Is that the right way? just \usemodule[zint]

For what it is worth, the [zint] variant does not work on my linux platform, the [m-zint] does work correctly. \usemodule[m-zint] \starttext \barcode[alternative=isbnx, text=9783865419026, width=4cm] \blank[big] \barcode[alternative=qrcode, text={wie weet waar willem wever woont}, width=3cm] \stoptext

On 18/12/2023 17:05, Ursula Hermann wrote:

After compiling \usemodule[m-zint] \starttext \barcode[alternative=isbnx, text=9783865419026, width=4cm] \blank[big] \barcode[alternative=qrcode, text={wie weet waar willem wever woont}, width=3cm] \stoptext

I got , what you see in the pdf.

Am 18.12.23 um 17:05 schrieb Ursula Hermann:

Dear List After compiling \usemodule[m-zint] \starttext \barcode[alternative=isbnx, text=9783865419026, width=4cm] \blank[big] \barcode[alternative=qrcode, text={wie weet waar willem wever woont}, width=3cm] \stoptext

I got , what you see in the pdf.

Are you using MkIV (LuaTeX) or LMTX (LuaMetaTeX)? What’s your ConTeXt version, and how did you install it? (TeX live, Linux distribution, LMTX distribution?) I guess a missing EPS means you load the MkIV version of the module, probably because "m-zint". Is there an error message with \loadmodule[zint]? I can’t help with Windows; since Hans developed it on Windows, it should work (but don’t ask me how). Hraban

On Mon Dec 18, 2023 at 9:35 PM CET, Pablo Rodriguez via ntg-context wrote:

On 12/18/23 20:34, Henning Hraban Ramm wrote:

...

[...] Are you using MkIV (LuaTeX) or LMTX (LuaMetaTeX)?

Many thanks for your reply, Hraban.

I understood my issue with your reply (I known, your answer is intended to Uschi).

It is also in the sent file:

Creator: LuaMetaTeX 2.10.11 20230908 + ConTeXt LMTX 2023.09.26 18:19 PDF Producer: LuaMetaTeX-2.10.11

...

I guess a missing EPS means you load the MkIV version of the module, probably because "m-zint".

I can’t help with Windows; since Hans developed it on Windows, it should work (but don’t ask me how).

I will try to explain what I understand from this (intended for Uschi).

Given that there are two modules (m-zint and zint), there are two options:

1. Either you use the LMTX module (\usemodule[zint]) and you need the Zint library (as explained in https://wiki.contextgarden.net/Barcodes#Zint_module).

2. Or you use the MkIV module (\usemodule[m-zint]) and you need the Zint binary installed and CMD should be able to invoke it (already knowing its past).

You may have the Zint binary installed, ConTeXt may be generating the required EPS files, but either Inkscape is not installed (or its path is unknown to the system), or ConTeXt cannot simply find where the converted PDF versions of the zint images are.

If I have the following source in testing-barcodes.tex:

\usemodule[m-zint] \starttext \startTEXpage[offset=1dk] \barcode[alternative=isbnx, text=9783865419026, width=4cm] \stopTEXpage \stoptext

ConTeXt compiles it generating to extra files (when compared to the pure zint module for LMTX only):

zint-isbnx-fe90eda0e93cf020312eps m_k_i_v_zint-isbnx-fe90eda0e93cf020312_eps_c60ccda70ef.pdf

(Removed some characters in strings so file names fit in a single line.)

The first file is generated by the Zint binary itself. The second one is the automatic conversion (through Inkscape) that ConTeXt needs to embed EPS (and SVG) files in the final PDF document.

If m_k_i_v_zint-*.pdf files are missing, the problem might be that Inkscape isn’t installed (or its path is unknown to the system).

If also zint-*.eps files are missing, you should find where Zint is generating them.

I will just add to the excellent answers above, that I very much recommend LMTX and the LMTX way of using the zint _library_. I published compiled versions of zint and couple of other libraries to the optional libraries repository: https://github.com/contextgarden/luametatex-optional-libraries https://github.com/contextgarden/luametatex-optional-libraries/releases/tag/... I tested the steps on the wiki and libzint.dll works without problems: i.e. install ConTeXt, create a few folders, move the dll and mtxrun --generate. My goto document for testing zint, that went without problems (even the hexagons!): \starttext \usemodule[zint] \barcode[alternative=isbnx, text=9783865419026, width=4cm] \barcode[alternative=qrcode, text={https://wiki.contextgarden.net}, width=3cm] \barcode[alternative=maxicode, text={test}, width=3cm] \stoptext Michal PS: Coincidentally zint 2.13 has been released just today. Usually every new zint release requires an update on the ConTeXt side, but older releases still work well with ConTeXt (e.g. currently ConTeXt supports 2.10, 2.11 and 2.12). The version linked above works.

Dear LIst, I used today the help of WinEdt , because of the PATH for the QR Code i wanted to try, and i found this one, sorry, a little bit long: PATH The PATH environment variable contains a list of directories where Windows should search for executable files when the path specification is not present in the command line. It is important that you understand that WinEdt launches external applications (such as TeX or LaTeX) through the associated command line (with additional parameters), which is passed to the appropriate Windows API function. WinEdt merely makes the process transparent by providing a customizable user-defined GUI (Graphical User Interface) in the form of a toolbar button (or a menu item) named LaTeX. WinEdt does not know in advance if and where you have installed your TeX and thus avoids calling the executables with a full path specification. However, it is strongly recommended that your PATH contains the TeX bin directory. In the Diagnosis page of this dialog, WinEdt will display the PATH variable particular to your system. Recent versions of TeX put their bin folder to the Windows PATH variable during installation. It is by this means that WinEdt can detect them automatically. If your PATH variable (as displayed in Diagnosis page) does not contain this folder (e.g. the folder where latex.exe is to be found), you probably don't have a properly installed TeX System! It is strongly recommended that you install TeX and Ghostscript as administrator or power user and thus allow the installations to initialize the required registry keys and environment variables. If you have any doubts about the PATH settings, start the Command Prompt from the Windows Start menu or WinEdt's Accessories menu (or WinEdt's toolbar button) and type the command: echo %PATH% This displays the value of your current PATH environment variable. If you have a good reason to put any folder on your Windows PATH, you can do so by changing the Windows environment variable PATH. This is done through the Windows Control Panel (System -> Advanced -> Environment Variables). Details depend on your version of Windows and are explained in Windows help. You should not expect extensive support from the WinEdt Team when it comes to configuring your Windows. Changes to the PATH variable made through WinEdt's PATH page in the Execution Modes interface affect only WinEdt and applications launched from it. In most cases, this is exactly what one wants. By default, you'll find something like this: [X][X][X][X] WinEdt inserts its own root folder %B to the PATH; this makes it possible to launch WinEdt from other applications (launched from it) without specifying the location of WinEdt.exe. For example, YAP's inverse search command can be manually defined in its Options dialog as: WinEdt.exe "[Open(|%f|);SelPar(%l,8);]" If necessary, you can add additional folders that will be inserted to the PATH variable. For example: %B;C:\My TeX\Win32\Bin;C:\My Accessories\Bin By default, WinEdt also detects the TeX and Ghostscript bin folders (or you can specify them manually in the Execution Modes interface). Unless these folders are already included in the PATH variable, WinEdt will insert them, thus making it easy to launch TeX executables (such as latex.exe) and GS's gswin64c.exe/gswin32c.exe, which is used for ps -> pdf conversion... In the above example, MiKTeX's bin folder got included to the PATH during MiKTeX's installation, while the GS folder had to be added by WinEdt... Note: Many users believe that putting some folder on their PATH will allow LaTeX to find ".sty" or ".cls" files in that folder. Wrong! TeX does not search the Windows PATH for any of its input files. TeX uses its own FNDB (for good reason) and you should consult your TeX manual to learn about where to place such files and how to properly install them! Windows PATH only allows WinEdt (or other programs, including the Command Prompt) to launch an executable with its name rather than full specification, which isn't known in advance, and which depends on where you have installed your accessories. If, after the executable is launched, it fails to perform the task, the PATH (or WinEdt) usually has nothing to do with the problem and you should focus on other reasons (including possible errors in your document – read the error message or log file produced by the accessory in question)... ________________________________ Variables WinEdt itself does not use any environment variables. However, applications that are launched from WinEdt may depend on them. In particular, TeX accessories can use such variables to obtain a list of additional directories where they search for input files, bibliography databases, etc... The documentation that comes with your TeX System or any other accessory describes the rules. You should consult this documentation in order to determine if using environment variables is the best solution, or whether there are faster alternatives available. Environment variables can be set and inspected through the Windows Control Panel (System -> Advanced -> Environment Variables). Details depend on your version of Windows. For an application launched from WinEdt it is also possible to set such values locally inside WinEdt because WinEdt's environmental block is inherited by them (when they are launched from WinEdt). This can be done by adding such definitions in the Variables page in the Execution Modes interface. Up to six such variables can be maintained through this page; a variable is enabled when the corresponding checkbox Var is checked. [X] For example, suppose that you want MiKTeX to search for input files in some non-standard fixed locations, e.g. C:\MyCurrentTeXProject and C:\MyTeXFiles and all subfolders inside this one, while your bibliography (.bib) files are stored in C:\MyTeXFiles\Bib directory. After consulting MiKTeX's help, you decide that you want to accomplish this by defining the appropriate environment variables TEXINPUTS and BIBINPUTS (even though this is not a recommended method as it can slow down the compilation). In this page define and enable the variables: BIBINPUTS .;C:/MyTeXFiles/Bib; TEXINPUTS .;C:/MyCurrentTeXProject;C:/MyTeXFiles//; The list of folders is separated by a semicolon, and "//" at the end indicates that all subfolders should be searched as well. Even though latest MiKTeX and TeX Live allow Windows-style specification of folders in environment variables, it is best to use UNIX-style (TeX usually expects and prefers directories to be separated by "/" rather "\" because the backslash is its control character). Furthermore, "//" at the end cannot be substituted with "\\". The initial dot "." is an instruction to search first in the current folder. The trailing semicolon ";" means a search in the TeX root if nothing is found in the specified folders. While not necessary when using MiKTeX, these are absolutely required when using TeX Live (otherwise, the current folder isn't searched and files in root folder won't be found)! Recursing through directories with many files can be pretty slow: you should consider faster alternatives (e.g. registering your own root directory) as described and recommended in MiKTeX's manual. But this is certainly not a WinEdt issue... Alternative method WinEdt's Macro Manual (among other things) explains how to use the SetEnvVar and GetEnvVar macro functions, should you require more information. And instead of using the Variables interface of the Execution Modes dialog, it is possible to add code directly to WinEdt's Local Startup macro (accessible through the Advanced -> Event Handlers section of the Options Interface): SetEnvVar("BIBINPUTS",".;C:/MyTeXFiles/Bib;"); SetEnvVar("TEXINPUTS",".;C:/MyCurrentTeXProject;C:/MyTeXFiles/"+"/;"); After adding the above lines to WinEdt's Local Startup macro, execute the command Run Startup Macro from the Macros menu. That's all. If you now launch a compilation from WinEdt, the accessories will use the modified variables. When in doubt about the value of any environment variable, you can use the command Define and Run Macro found in the Macros menu and execute the macro: Prompt("%@('Environment Variable');"); Note: This is where WinEdt's involvement with environment variables ends (you can set and inspect them through WinEdt's macros or through this interface). The meaning of such variables is described in the documentation that comes with your accessories or TeX System (e.g. MiKTeX's manual). Whether or not they work as you expect depends on your TeX System (but not on WinEdt!). Contrary to what many users believe, neither WinEdt's nor the Windows PATH variable have anything to do with where TeX is searching for its input files! ________________________________ Diagnosis WinEdt displays crucial information about your TeX System and accessories in this page. If you encounter problems with launching a certain accessory, this report can be used to see if the application is installed and if it can be found. If the problem is only with detecting the executable, then the information in the Troubleshooting section should guide you in manually fixing the problem. If, on the other hand, the executable can be located but it does not run properly, it means that there are some problems with it (or your document source) outside WinEdt. WinEdt cannot detect and fix this kind of problem and you'll have to consult the documentation pertaining to that accessory or TeX System. If WinEdt cannot find any trace of your TeX System or other accessories, it is likely that they are not properly installed. Reinstalling the problematic software and restarting WinEdt after that might be by far the best way to resolve the situation. This allows for smooth upgrades while manual corrections may have to be maintained when you upgrade your TeX System or accessories such as Ghostscript or Adobe Reader. If a problem with any external accessory appears all of a suddenly, the reason is almost certainly that your registry no longer contains the required information that would allow WinEdt to automatically detect the application. This can happen if you performed a registry cleanup to remove a virus or correct some other problem. Registry keys may also get "lost" during Windows upgrades or major updates and, in some cases, during software installation or removal... In such a case, reinstalling the problematic accessory and letting its installer update the registry might be the easiest way to fix the problem. It is important that you use a power (or administrator) account when installing applications: otherwise the registry update may fail due to access restrictions. If you are not an experienced user, let the programs install with their defaults and allow the application (such as Adobe Reader) to start after successful installation. WinEdt has to be restarted before it can properly detect newly installed accessories. Reinstalling WinEdt is not necessary and does not improve detection of external applications (although, for some reason, this is exactly what many users try first)... If you are not sure whether or not an application or a TeX System has been successfully installed, check the Windows Start menu. You should be able to launch it from there! Below is an example of a healthy MiKTeX installation. No manual corrections were required and all accessories are detected on the PATH or in Windows registry. Note that WinEdt detected MiKTeX's bin folder, Ghostscript's bin folder and inserted its own root folder to its private PATH, which is also used by applications launched from within WinEdt. If your report significantly differs from this one, you should consider reinstalling the problematic accessories or your TeX System. In particular, if some executables are missing, you have no choice but to (re)install them. MiKTeX users can use the MiKTeX Package Manager to install additional components (assuming that the core of the MiKTeX System is properly installed). -------------------------------------------------------------------------------- File: "C:\Users\xxx\AppData\Roaming\WinEdt Team\WinEdt 10\TeX.log" Date: Monday, May 7, 2018 13:49 Summary :-) =========== Your TeX installation appears to be fine. If you experience problems after an application has been launched this usually isn't a WinEdt-related matter. In such case, you should test a problematic application from the Command Prompt, consult the documentation that comes with your (TeX) software, and try to locate the real source of your problem... ________________________________________________________________________________ WinEdt 10 (v. 10.3) [Build: 20180507 - 64-bit Caption: WinEdt 10.3 Default Mode: TeX Default Type: .tex Default Path: %P *** Account (UAC) Status: Restricted User *** Configuration: Default:MiKTeX *** TeX System: MiKTeX *** User Profile: Enabled *** %B: C:\Program Files\WinEdt Team\WinEdt 10 *** %b: C:\Users\xxx\AppData\Roaming\WinEdt Team\WinEdt 10 *** WinEdt PATH: "C:\Program Files\WinEdt Team\WinEdt 10; C:\Program Files\MiKTeX 2.9\miktex\bin; C:\texlive\2016\bin\win32; C:\Program Files\Embarcadero\RAD Studio\14.0\bin; C:\Users\Public\Documents\RAD Studio\14.0\Bpl; C:\Windows\system32; C:\Windows; C:\Windows\System32\Wbem; C:\Windows\System32\WindowsPowerShell\v1.0\; C:\Program Files\MiKTeX 2.9\miktex\bin; C:\Users\xxx\AppData\Roaming\MiKTeX\2.9\miktex\bin\" *** Windows PATH: "C:\texlive\2016\bin\win32; C:\Program Files\Embarcadero\RAD Studio\14.0\bin; C:\Users\Public\Documents\RAD Studio\14.0\Bpl; C:\Windows\system32; C:\Windows; C:\Windows\System32\Wbem; C:\Windows\System32\WindowsPowerShell\v1.0\; C:\Program Files\MiKTeX 2.9\miktex\bin; C:\Users\xxx\AppData\Roaming\MiKTeX\2.9\miktex\bin\" ________________________________________________________________________________ Searching for Executables: ========================== WinEdt will try to locate external executables based on the PATH Environment Variable and Windows Registry. If some components are not found follow the instructions. Some applications such as, for example, GS or GSView are optional; you can safely ignore any messages about the "missing" accessories that you are not intending to use... TeX-Root: OK C:\Program Files\MiKTeX 2.9 TeX-Bin: OK C:\Program Files\MiKTeX 2.9\miktex\bin TeX-Help Folder: OK C:\Program Files\MiKTeX 2.9\doc DVIView: OK (PATH yap.exe)* C:\Program Files\MiKTeX 2.9\miktex\bin\yap.exe TeX-Bin (TeX.exe): OK* C:\Program Files\MiKTeX 2.9\miktex\bin\tex.exe TeX-Bin (LaTeX.exe): OK* C:\Program Files\MiKTeX 2.9\miktex\bin\latex.exe TeX-Bin (PDFTeX.exe): OK* C:\Program Files\MiKTeX 2.9\miktex\bin\pdftex.exe TeX-Bin (PDFLaTeX.exe): OK* C:\Program Files\MiKTeX 2.9\miktex\bin\pdflatex.exe TeX-Bin (BibTeX.exe): OK* C:\Program Files\MiKTeX 2.9\miktex\bin\bibtex.exe TeX-Bin (dvips.exe): OK* C:\Program Files\MiKTeX 2.9\miktex\bin\dvips.exe TeX-Bin (ps2pdf.exe): OK* C:\Program Files\MiKTeX 2.9\miktex\bin\ps2pdf.exe TeX-Bin (dvipdfmx.exe): OK* C:\Program Files\MiKTeX 2.9\miktex\bin\dvipdfmx.exe TeX-Bin (mf.exe): OK* C:\Program Files\MiKTeX 2.9\miktex\bin\mf.exe TeX-Bin (mpost.exe): OK* C:\Program Files\MiKTeX 2.9\miktex\bin\mpost.exe MiKTeX-Bin (TeXify.exe): OK* C:\Program Files\MiKTeX 2.9\miktex\bin\texify.exe My question is: Should I put the PATH in WinEdt or in Windows? Or in ConTeXt? $TEXROOT/tex/texmf-$ARCH/bin/lib/luametatex/zint Many thanks Uschi ________________________________ Von: Henning Hraban Ramm Gesendet: Montag, 18. Dezember 2023 20:34:15 An: ntg-context@ntg.nl Betreff: [NTG-context] Re: QR Code Am 18.12.23 um 17:05 schrieb Ursula Hermann:

Dear List After compiling \usemodule[m-zint] \starttext \barcode[alternative=isbnx, text=9783865419026, width=4cm] \blank[big] \barcode[alternative=qrcode, text={wie weet waar willem wever woont}, width=3cm] \stoptext

I got , what you see in the pdf.

Are you using MkIV (LuaTeX) or LMTX (LuaMetaTeX)? What’s your ConTeXt version, and how did you install it? (TeX live, Linux distribution, LMTX distribution?) I guess a missing EPS means you load the MkIV version of the module, probably because "m-zint". Is there an error message with \loadmodule[zint]? I can’t help with Windows; since Hans developed it on Windows, it should work (but don’t ask me how). Hraban ___________________________________________________________________________________ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / https://mailman.ntg.nl/mailman3/lists/ntg-context.ntg.nl webpage : https://www.pragma-ade.nl / https://context.aanhet.net (mirror) archive : https://github.com/contextgarden/context wiki : https://wiki.contextgarden.net ___________________________________________________________________________________