Re: [XeTeX] 64-bit binaries

[Akira Kakuto]

Dear Bobby,

On 2021/06/05 2:36, Bobby de Vos wrote:

TeX Live and W32TeX differs in directory structure and versions of binaries.
Please use files in TLW64 folder for TeX Live and don't use files in win64 
folder.


I am confused by this. I am currently using W32TeX as a minimal TeX 
installation [0] that is used by another application (so not TeX Live as 
installed by [1]). You can see from the update script [2] that I use that I 
download ...



In the case of W32TeX, please use files in the folder win64. In the case of TeX 
Live, please use
files in the folder TLW64.

In W32TeX, binaries are latest ones, but large number of packages and fonts are 
missing.

Best,
Akira

Re: [XeTeX] 64-bit binaries

[Bobby de Vos]

On 2021-06-02 4:07 p.m., Akira Kakuto wrote:

> On 2021/06/03 5:01, Bobby de Vos wrote:
>> I noticed that there are two download locations for 64 bit binaries
>> mentioned at http://w32tex.org/
>>
>> One is in a section called /64bit Windows binaries for TeX Live/ and
>> links to https://ctan.org/tex-archive/systems/win32/w32tex/TLW64
>>
>> The other is location is present in the various mirrors (such as Ring
>> Server 1) in the win64 folder.
>>
>> Which location should I be getting 64 bit binaries from?
>>
>
> TLW64 folder is for TeX Live. win64 folder is for W32TeX.

Thanks, that is very helpful.

> TeX Live and W32TeX differs in directory structure and versions of
> binaries.
> Please use files in TLW64 folder for TeX Live and don't use files in
> win64 folder.

I am confused by this. I am currently using W32TeX as a minimal TeX
installation [0] that is used by another application (so not TeX Live as
installed by [1]). You can see from the update script [2] that I use
that I download

{dvipdfm-w32,web2c-lib,web2c-w32,xetex-w32}.tar.xz

Are you saying that I should use the files in the TLW64 with this TeX
tree, or download

{dvipdfm-w64,web2c-w64,xetex-w64}.tar.xz and also the web2c-lib.tar.xz
from the above list?

[0] https://github.com/sillsdev/ptx2pdf/tree/master/xetex

[1] https://www.tug.org/texlive/

[2] https://github.com/sillsdev/ptx2pdf/blob/master/bin/update-xetex.bash

-- 
Bobby de Vos
/bobby_de...@sil.org/

Re: [XeTeX] 64-bit binaries

[Philip Taylor]

Bobby de Vos wrote:


Philip,

The URL I would give is the same you you have mentioned. The win64 
folder is towards the bottom of the list, the directories are not 
sorted together, but everything is sorted, but with case sensitivity. 
So TLW64 comes way before win64.


Bobby



Ah, thank you Bobby.  I supposed that I am used to seeing directories 
("folders") clustered together either at the top or at the bottom of a 
directory listing, and failed to realise that in this instance files and 
directories are intermixed.

--
/Philip Taylor/

Re: [XeTeX] 64-bit binaries

[Bobby de Vos]

Philip,

The URL I would give is the same you you have mentioned. The win64
folder is towards the bottom of the list, the directories are not sorted
together, but everything is sorted, but with case sensitivity. So TLW64
comes way before win64.

Bobby

On 2021-06-02 3:01 p.m., Philip Taylor wrote:
> Bobby de Vos wrote:
>
>> I noticed that there are two download locations for 64 bit binaries
>> mentioned at http://w32tex.org/
>>
>> One is in a section called /64bit Windows binaries for TeX Live/ and
>> links to https://ctan.org/tex-archive/systems/win32/w32tex/TLW64
>>
>> The other is location is present in the various mirrors (such as Ring
>> Server 1) in the win64 folder.
>>
>
> Following the w32tex.org link to Ring Server 1
> ,
> I see no mention of a "win64" folder, while I do see a TLW64 directory
> ;
> could you give the URL at which the "win64" folder is visible, please ?
> -- 
> /Philip Taylor/
-- 
Bobby de Vos
/bobby_de...@sil.org/

Re: [XeTeX] [texworks] Adobe PDF, Adobe Acrobat/Reader, Microsoft Word, XeTeX, and (x)dvipdfm(x).

[Stefan Löffler]

Hi Philip,

On 29.05.21 11:22, Philip Taylor wrote:
Hallo Akira-san, and many thanks for the information.  As far as I can 
see, the real problem lies in the fact that "only documents opened by 
`pdfopen' can be closed by `pdfclose'" [This is a problem because 
TeXworks appears not to use `pdfopen' when instructed to "Print 
PDF..."].  I assume that this restriction exists because `pdfopen' 
obtains some sort of descriptor/handle to the file which it has 
opened, which it then uses to close the file, but I have checked and 
ascertained that MS Word does not suffer from this problem — I can 
open a Word-generated PDF by double-clicking on it in Windows 
Explorer, and if I then open the original Word document and tell it to 
"Save as PDF", Word manages to tell Adobe Acrobat to close the file 
even though it did not initiate the open.  I therefore have two 
questions :


 1. Is there any possibility that `pdfclose' could be enhanced such
that `pdfclose' can open any currently open PDF, not just one that
it has itself opened; and



In principle, yes (if I understand you correctly) - at least for 
Acrobat. https://www.adobe.com/go/acrobatsdk_iacguide lists a 
CloseAllDocs() function. There doesn't seem to be an easy way to get a 
list of all open files, though.



 1. Would it be possible to develop a `pdfDDE' program that would
iterate over the known set of DDE server names and report which
(if any) allow successful communication with the server, as
determining the DDE server name appears to be somewhat problematic ?



Yes, it seems to be possible to communicate with all DDE-aware 
applications (see 
https://docs.microsoft.com/en-us/windows/win32/dataxchg/using-dynamic-data-exchange). 
However, many of them may not be PDF readers, and their way of 
communicating (supported commands, etc.) are application-specific as 
well. So without knowing what to look for, it seems impossible to 
actually find something useful.
That being said, according to 
https://wiki.tcl-lang.org/page/Howto+open+PDF+with+Adobe+Acrobat+or+Reader+using+DDE, 
it might be possible to determine the DDE name of a (properly installed) 
Acrobat version from the registry (assuming the syntax doesn't change 
from version to version).


In the meantime I will raise this issue on the TeXworks list, since if 
TeXworks could use `pdfopen' and `pdfclose' (the former when 
instructed to "Print PDF...", the latter before calling XeTeX), then 
that would address at least a part of the current problem.




I'm reluctant to force the use of pdfopen, as this is a separate 
program/script that need not be installed (it definitely isn't on my 
(Linux) system). I could imagine, though, implementing the possibility 
to run certain commands before typesetting, such as sending DDE command 
to Acrobat on Windows), similar to what I think is done in TeXnicCenter 
and probably others.


Does anyone have any experience with other PDF readers? Is the same 
problem (no write access to open pdfs) present in, e.g., FoxitReader, 
SumatraPDF, etc.? Or is it just Adobe-specific?


HTH
Stefan