From igor.liferenko at gmail.com Fri Oct 15 08:53:38 2021 From: igor.liferenko at gmail.com (Igor Liferenko) Date: Fri, 15 Oct 2021 13:53:38 +0700 Subject: [dvipdfmx] Default resolution 600dpi cannot be changed In-Reply-To: References: Message-ID: Hi, >> But dvipdfmx does not respect `-r' option - resolution >> 600dpi is always used. This can be demonstrated the following way: 1) Create test.dvi from this input: A \bye 2) Override mktexpk script with this script: #!/bin/sh exit 1 3) Run: T1FONTS=/none TFMFONTS=/none PKFONTS=/none dvipdfmx -r 300 test.dvi The output contains this line: kpathsea: Running mktexpk --mfmode / --bdpi 600 --mag 1+0/600 --dpi 600 cmr10 So, resolution passed to mktexpk (600) does not match the one specified in argument (300). Regards, Igor From igor.liferenko at gmail.com Fri Oct 15 09:15:40 2021 From: igor.liferenko at gmail.com (Igor Liferenko) Date: Fri, 15 Oct 2021 14:15:40 +0700 Subject: [dvipdfmx] Default resolution 600dpi cannot be changed In-Reply-To: References: Message-ID: > So, resolution passed to mktexpk (600) does not match the one > specified in argument (300). Also, notice the following fact: if we use default mktexpk script, but in the beginning of it add this line: set -- --mfmode / --bdpi 300 --mag 1+0/300 --dpi 300 cmr10 then dvipdfmx uses cmr10.300pk which mktexpk generates. From tex at 2krueger.de Fri Oct 29 01:52:22 2021 From: tex at 2krueger.de (Marcel Fabian =?utf-8?Q?Kr=C3=BCger?=) Date: Fri, 29 Oct 2021 01:52:22 +0200 Subject: [dvipdfmx] [PATCH] Embedding of CFF based fonts without Private dictionary Message-ID: <20211028235222.pt4z4cwmi445f5s5@beeblebrox> Hi, some time ago, a dvipdfmx bug got reported on TeX StackExchange (https://tex.stackexchange.com/questions/610371/fonts-without-bold-italic-xelatex): When embedding a CFF based OpenType font which does not contain a Private dictionary, dvipdfmx segfaults due to a dereferenced NULL pointer. I'm suggesting the patch below to fix this. Best regards, Marcel --- texk/dvipdfm-x/cidtype0.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/texk/dvipdfm-x/cidtype0.c b/texk/dvipdfm-x/cidtype0.c index fd00dd7bd..86a90af28 100644 --- a/texk/dvipdfm-x/cidtype0.c +++ b/texk/dvipdfm-x/cidtype0.c @@ -1401,7 +1401,11 @@ CIDFont_type0_t1cdofont (pdf_font *font) cff_add_string(cffont, "Identity", 1); cff_dict_update(cffont->topdict, cffont); - cff_dict_update(cffont->private[0], cffont); + + if (cffont->private && cffont->private[0]) { + cff_dict_update(cffont->private[0], cffont); + } + cff_update_string(cffont); /* CFF code need to be rewrote... */ -- 2.33.1 From naveen521kk at gmail.com Sat Oct 30 12:41:31 2021 From: naveen521kk at gmail.com (Naveen M K) Date: Sat, 30 Oct 2021 16:11:31 +0530 Subject: [dvipdfmx] [PATCH] mingw: Don't copy libtool wrappers Message-ID: <8e1a2d90-6666-2277-6fc8-7c1fe68b1340@gmail.com> Hi, Recently someone reported[1] that extractbb.exe isn't working as expected. I found that they were libtool wrappers which shouldn't be installed outside of build tree. I also found this affect all the following executables: - extractbb.exe - dvipdfm.exe - dvipdfmx.exe - ebb.exe I am suggesting the following patch so that this doesn't happen. I have applied this patch in MSYS2[2] and it seems to work. [1].. https://github.com/msys2/msys2-texlive/issues/18 [2].. https://github.com/msys2/MINGW-packages/pull/9840 Naveen M K -------------- next part -------------- From 41d467a60daabb971322f99bf087701ff5dce097 Mon Sep 17 00:00:00 2001 From: Naveen M K Date: Fri, 22 Oct 2021 15:03:31 +0530 Subject: [PATCH] texk/dvipdfm-x: Don't copy libtool wrapper Previously libtools wrapper was copied as `extractbb.exe` and other which is not to be done. So, now use libtool to copy the files rather than doing manually so that this doesn't happen. Signed-off-by: Naveen M K --- texk/dvipdfm-x/Makefile.am | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/texk/dvipdfm-x/Makefile.am b/texk/dvipdfm-x/Makefile.am index c738137d3d..6c845232ab 100644 --- a/texk/dvipdfm-x/Makefile.am +++ b/texk/dvipdfm-x/Makefile.am @@ -209,10 +209,10 @@ dist_cmapdata_DATA = data/EUC-UCS2 install-exec-hook: install-bin-links if WIN32 - $(INSTALL_PROGRAM) call_xdvipdfmx$(EXEEXT) $(DESTDIR)$(bindir)/dvipdfm$(EXEEXT) - $(INSTALL_PROGRAM) call_xdvipdfmx$(EXEEXT) $(DESTDIR)$(bindir)/dvipdfmx$(EXEEXT) - $(INSTALL_PROGRAM) call_xdvipdfmx$(EXEEXT) $(DESTDIR)$(bindir)/ebb$(EXEEXT) - $(INSTALL_PROGRAM) call_xdvipdfmx$(EXEEXT) $(DESTDIR)$(bindir)/extractbb$(EXEEXT) + $(INSTALL_PROGRAM_ENV) $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL_PROGRAM) call_xdvipdfmx$(EXEEXT) "$(DESTDIR)$(bindir)/dvipdfm$(EXEEXT)" + $(INSTALL_PROGRAM_ENV) $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL_PROGRAM) call_xdvipdfmx$(EXEEXT) "$(DESTDIR)$(bindir)/dvipdfmx$(EXEEXT)" + $(INSTALL_PROGRAM_ENV) $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL_PROGRAM) call_xdvipdfmx$(EXEEXT) "$(DESTDIR)$(bindir)/ebb$(EXEEXT)" + $(INSTALL_PROGRAM_ENV) $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL_PROGRAM) call_xdvipdfmx$(EXEEXT) "$(DESTDIR)$(bindir)/extractbb$(EXEEXT)" endif WIN32 install-data-hook: install-man1-links From karl at freefriends.org Sat Oct 30 22:22:27 2021 From: karl at freefriends.org (Karl Berry) Date: Sat, 30 Oct 2021 14:22:27 -0600 Subject: [dvipdfmx] [PATCH] mingw: Don't copy libtool wrappers In-Reply-To: <8e1a2d90-6666-2277-6fc8-7c1fe68b1340@gmail.com> Message-ID: <202110302022.19UKMRKC011632@freefriends.org> install-exec-hook: install-bin-links if WIN32 - $(INSTALL_PROGRAM) call_xdvipdfmx$(EXEEXT) $(DESTDIR)$(bindir)/dvipdfm$(EXEEXT) Any idea why this install-exec-hook exists in the first place? I don't see it for other programs in the TL tree. From shunsaku.hirata74 at gmail.com Sun Oct 31 04:07:08 2021 From: shunsaku.hirata74 at gmail.com (Shunsaku Hirata) Date: Sun, 31 Oct 2021 12:07:08 +0900 Subject: [dvipdfmx] [PATCH] mingw: Don't copy libtool wrappers In-Reply-To: <202110302022.19UKMRKC011632@freefriends.org> References: <8e1a2d90-6666-2277-6fc8-7c1fe68b1340@gmail.com> <202110302022.19UKMRKC011632@freefriends.org> Message-ID: Hi Karl, 2021?10?31?(?) 5:22 Karl Berry : > > install-exec-hook: install-bin-links > if WIN32 > - $(INSTALL_PROGRAM) call_xdvipdfmx$(EXEEXT) $(DESTDIR)$(bindir)/dvipdfm$(EXEEXT) > > Any idea why this install-exec-hook exists in the first place? > I don't see it for other programs in the TL tree. I don't know how this was introduced. However, if you just want to know why such a wrapper is needed: dvipdfmx changes it's behavior depending on the program name it was called, e.g., it behaves as extractbb when "xdvipdfmx.exe" is called through the wrapper "extractbb.exe". I think this Windows specific behavior comes from the autoconf macro "KPSE_WIN32_CALL" described in the following page: https://www.tug.org/texlive/doc/tlbuild.html#Macros-for-Windows A wrapper is used just to emulate symbolic links on Windows platforms. Thanks, Shunsaku Hirata From shunsaku.hirata74 at gmail.com Sun Oct 31 04:35:54 2021 From: shunsaku.hirata74 at gmail.com (Shunsaku Hirata) Date: Sun, 31 Oct 2021 12:35:54 +0900 Subject: [dvipdfmx] [PATCH] mingw: Don't copy libtool wrappers In-Reply-To: References: Message-ID: <89133B05-7E0B-40A2-B1A9-475090C2C070@gmail.com> > I think this Windows specific behavior comes from the autoconf > macro "KPSE_WIN32_CALL" described in the following page: > > https://www.tug.org/texlive/doc/tlbuild.html#Macros-for-Windows Sorry I hadn't read the original report since it was automatically sent to the junk mail folder. This is not true. Thanks, Shunsaku Hirata From naveen521kk at gmail.com Sun Oct 31 10:25:43 2021 From: naveen521kk at gmail.com (Naveen M K) Date: Sun, 31 Oct 2021 14:55:43 +0530 Subject: [dvipdfmx] [PATCH] mingw: Don't copy libtool wrappers In-Reply-To: <202110302022.19UKMRKC011632@freefriends.org> References: <202110302022.19UKMRKC011632@freefriends.org> Message-ID: Hi Karl, On 31-10-2021 01:52, Karl Berry wrote: > Any idea why this install-exec-hook exists in the first place? > I don't see it for other programs in the TL tree. Not sure how that was introduced. I guess it exists there to avoid building "callexe.c" (the wrapper I guess) multiple times; instead just copying and renaming it to required executables. I also don't how this is done in other places. Probably, this isn't the prefect patch but at-least "it works". Naveen M K