- ntg-pdftex - NTG Mailing Lists

[ pdftex-Patches-709 ] merging patch 597 by Hartmut
by noreply＠sarovar.org 04 Dec '06

04 Dec '06

Patches item #709, was opened at 2006-12-04 08:21 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=709&group_id=106 Category: Fonts Group: v1.40.0 Status: Open Resolution: None Priority: 6 Submitted By: The Thanh Han (hanthethanh) Assigned to: Hartmut Henkel (hhenkel) Summary: merging patch 597 by Hartmut Initial Comment: This is a patch against pdftex-1.40.0-beta-20061018 that merges patch 597 by Hartmut and does some clean up in the font mechanism. Testing welcome very much. ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2006-12-04 13:25 Message: Logged In: YES user_id=710 are you saying that you have troubles applying the patch against pdftex-1.40.0-beta-20061017? Can you please try to apply against pdftex-1.40.0-beta-20061018? I have checked everything again from the beginning as follows: - download and unpack http://sarovar.org/download.php/1100/pdftex-1.40.0-beta-20061017.tar.bz2 - download, ungzip and apply http://sarovar.org/download.php/1108/pdftex-1.40.0-beta-20061017-20061108.d… - download http://sarovar.org/tracker/download.php/106/495/709/237/pdftex-20061204-2.p… - cd /path/to/pdftex-1.40.0-beta-20061017/src - patch -p1 --dry-run /path/to/pdftex-20061204-2.patch The patch applied ok, apart from change-files.txt (I removed it from pdftexdir, as it's no longer relevant to pdftex). ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-12-04 12:33 Message: Logged In: YES user_id=421 I'm having troubles applying pdftex-20061204-2.patch against pdftex-1.40.0-beta-20061017, especially pdftex.web. Can you attach a diff against 1.40.0-beta-20061108 or your patched pdftex.web? ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2006-12-04 11:02 Message: Logged In: YES user_id=710 I updated the patch to revert auto kerns to be explicit. This will disable hyphenation if auto kern is used. On the other hand this is much more robust. The pending problems are: bug #693: still trying bug #484: will not be fixed, better treat it as a limitation bug #465: unlikely to be fixed ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=709&group_id=106

1 0

[ pdftex-Patches-709 ] merging patch 597 by Hartmut
by noreply＠sarovar.org 04 Dec '06

04 Dec '06

Patches item #709, was opened at 2006-12-04 09:21 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=709&group_id=106 Category: Fonts Group: v1.40.0 Status: Open Resolution: None Priority: 6 Submitted By: The Thanh Han (hanthethanh) Assigned to: Hartmut Henkel (hhenkel) Summary: merging patch 597 by Hartmut Initial Comment: This is a patch against pdftex-1.40.0-beta-20061018 that merges patch 597 by Hartmut and does some clean up in the font mechanism. Testing welcome very much. ---------------------------------------------------------------------- >Comment By: Martin Schröder (oneiros) Date: 2006-12-04 13:33 Message: Logged In: YES user_id=421 I'm having troubles applying pdftex-20061204-2.patch against pdftex-1.40.0-beta-20061017, especially pdftex.web. Can you attach a diff against 1.40.0-beta-20061108 or your patched pdftex.web? ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2006-12-04 12:02 Message: Logged In: YES user_id=710 I updated the patch to revert auto kerns to be explicit. This will disable hyphenation if auto kern is used. On the other hand this is much more robust. The pending problems are: bug #693: still trying bug #484: will not be fixed, better treat it as a limitation bug #465: unlikely to be fixed ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=709&group_id=106

1 0

[ pdftex-Patches-709 ] merging patch 597 by Hartmut
by noreply＠sarovar.org 04 Dec '06

04 Dec '06

Patches item #709, was opened at 2006-12-04 09:21 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=709&group_id=106 >Category: Fonts >Group: v1.40.0 Status: Open Resolution: None >Priority: 6 Submitted By: The Thanh Han (hanthethanh) >Assigned to: Hartmut Henkel (hhenkel) Summary: merging patch 597 by Hartmut Initial Comment: This is a patch against pdftex-1.40.0-beta-20061018 that merges patch 597 by Hartmut and does some clean up in the font mechanism. Testing welcome very much. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2006-12-04 12:02 Message: Logged In: YES user_id=710 I updated the patch to revert auto kerns to be explicit. This will disable hyphenation if auto kern is used. On the other hand this is much more robust. The pending problems are: bug #693: still trying bug #484: will not be fixed, better treat it as a limitation bug #465: unlikely to be fixed ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=709&group_id=106

1 0

[ pdftex-Patches-709 ] merging patch 597 by Hartmut
by noreply＠sarovar.org 04 Dec '06

04 Dec '06

Patches item #709, was opened at 2006-12-04 08:21 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=709&group_id=106 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: The Thanh Han (hanthethanh) Assigned to: Nobody (None) Summary: merging patch 597 by Hartmut Initial Comment: This is a patch against pdftex-1.40.0-beta-20061018 that merges patch 597 by Hartmut and does some clean up in the font mechanism. Testing welcome very much. ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2006-12-04 11:02 Message: Logged In: YES user_id=710 I updated the patch to revert auto kerns to be explicit. This will disable hyphenation if auto kern is used. On the other hand this is much more robust. The pending problems are: bug #693: still trying bug #484: will not be fixed, better treat it as a limitation bug #465: unlikely to be fixed ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=709&group_id=106

1 0

[ pdftex-Patches-709 ] merging patch 597 by Hartmut
by noreply＠sarovar.org 04 Dec '06

04 Dec '06

Patches item #709, was opened at 2006-12-04 08:21 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=709&group_id=106 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: The Thanh Han (hanthethanh) Assigned to: Nobody (None) Summary: merging patch 597 by Hartmut Initial Comment: This is a patch against pdftex-1.40.0-beta-20061018 that merges patch 597 by Hartmut and does some clean up in the font mechanism. Testing welcome very much. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=709&group_id=106

1 0

[ pdftex-Patches-462 ] HZ font expansion by text matrix manipulation
by noreply＠sarovar.org 01 Dec '06

01 Dec '06

Patches item #462, was opened at 2005-12-23 23:35 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=462&group_id=106 Category: Positioning Group: v1.40.0 Status: Open >Resolution: Postponed Priority: 5 Submitted By: Hartmut Henkel (hhenkel) Assigned to: The Thanh Han (hanthethanh) Summary: HZ font expansion by text matrix manipulation Initial Comment: Use textmatrix Tm instead of /FontMatrix for font expansion. Then a font file will be embedded only once for all expansion factors. Gives smaller PDF files. Works then also for non-embedded fonts. TrueType not tried yet. Rough patch only, incomplete, work in progress, no warranty, not for production. Regards, Hartmut ---------------------------------------------------------------------- >Comment By: Martin Schröder (oneiros) Date: 2006-12-01 11:26 Message: Logged In: YES user_id=421 We've removed it from beta again; it introduces additional problems and needs more time to stabilize. ---------------------------------------------------------------------- Comment By: Robert (schlcht) Date: 2006-09-30 16:22 Message: Logged In: YES user_id=2217 It's great to have this included! However, pdftex is now a bit too keen on autoexpanding -- it does so, even if `autoexpand' is not specified. Although the pre-created metrics are read, the physical font (pfb resp. pk) is ignored. As has been discussed re: bug 304, *not* using autoexpansion gives better results for MM (and MF) fonts, since the fonts are not stretched blindly but stroke widths are adjusted etc. Compare the output of the test file from bugs/304 compiled with an old pdftex and with 20060928. With the latter, the strokes are slightly heavier. Same here (with an existing file cmr10+100.mf): \pdfadjustspacing2 \pdfmapline{ cmr10} \pdfmapline{+cmr10+100} \font\cmr =cmr10 \cmr \pdffontexpand\cmr 100 0 100 %autoexpand Hamburgefonts\par \parfillskip 0pt Hamburgefonts \bye ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-02-13 19:41 Message: Logged In: YES user_id=421 The last word from Hartmut was that it's not ready yet and he'd be working on an improved version. ---------------------------------------------------------------------- Comment By: Robert (schlcht) Date: 2006-02-13 19:05 Message: Logged In: YES user_id=2217 Will this make it into 1.40? I would love to see it included. I've tested it a bit and did not find any problems (I'm also using it for the pre-built microtype documentation on CTAN). Regards, Robert ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=462&group_id=106

1 0

[ pdftex-Patches-705 ] Patch to allow vf_nf grow dynamically
by noreply＠sarovar.org 26 Nov '06

26 Nov '06

Patches item #705, was opened at 2006-11-22 20:52 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=705&group_id=106 Category: Fonts >Group: v1.40.0 Status: Open Resolution: Accepted Priority: 5 Submitted By: The Thanh Han (hanthethanh) Assigned to: Hartmut Henkel (hhenkel) Summary: Patch to allow vf_nf grow dynamically Initial Comment: This patch allows the array vf_e_fnts and vf_i_fnts grow dynamically, instead of having fixed size font_max as currently. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-11-26 21:01 Message: Logged In: YES user_id=421 This has been included in version 1.40 ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2006-11-25 10:58 Message: Logged In: NO Hi! It's been applied on Debian/unstable, and it works! Top notch! Thanks Danai SAE-HAN ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2006-11-23 08:18 Message: Logged In: YES user_id=710 yes. this patch also contains a fix by Akira the segfault bug (one line added) and a fix for bug #692 (another line). It's not hard to fix bug #694 and #696 too. However I didn't mention them, as I am considering to remove the relevant code. ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2006-11-23 02:26 Message: Logged In: NO Hi! Does this mean that the bug "SGML output fails with pdflatex" will also be solved? Cheers Danai SAE-HAN ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=705&group_id=106

1 0

[ pdftex-Patches-705 ] Patch to allow vf_nf grow dynamically
by noreply＠sarovar.org 26 Nov '06

26 Nov '06

Patches item #705, was opened at 2006-11-22 20:52 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=705&group_id=106 >Category: Fonts >Group: v1.30.0 Status: Open >Resolution: Accepted Priority: 5 Submitted By: The Thanh Han (hanthethanh) >Assigned to: Hartmut Henkel (hhenkel) Summary: Patch to allow vf_nf grow dynamically Initial Comment: This patch allows the array vf_e_fnts and vf_i_fnts grow dynamically, instead of having fixed size font_max as currently. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-11-26 21:01 Message: Logged In: YES user_id=421 This has been included in version 1.40 ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2006-11-25 10:58 Message: Logged In: NO Hi! It's been applied on Debian/unstable, and it works! Top notch! Thanks Danai SAE-HAN ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2006-11-23 08:18 Message: Logged In: YES user_id=710 yes. this patch also contains a fix by Akira the segfault bug (one line added) and a fix for bug #692 (another line). It's not hard to fix bug #694 and #696 too. However I didn't mention them, as I am considering to remove the relevant code. ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2006-11-23 02:26 Message: Logged In: NO Hi! Does this mean that the bug "SGML output fails with pdflatex" will also be solved? Cheers Danai SAE-HAN ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=705&group_id=106

1 0

[ pdftex-Patches-705 ] Patch to allow vf_nf grow dynamically
by noreply＠sarovar.org 25 Nov '06

25 Nov '06

Patches item #705, was opened at 2006-11-23 01:22 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=705&group_id=106 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: The Thanh Han (hanthethanh) Assigned to: Nobody (None) Summary: Patch to allow vf_nf grow dynamically Initial Comment: This patch allows the array vf_e_fnts and vf_i_fnts grow dynamically, instead of having fixed size font_max as currently. ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2006-11-25 15:28 Message: Logged In: NO Hi! It's been applied on Debian/unstable, and it works! Top notch! Thanks Danai SAE-HAN ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2006-11-23 12:48 Message: Logged In: YES user_id=710 yes. this patch also contains a fix by Akira the segfault bug (one line added) and a fix for bug #692 (another line). It's not hard to fix bug #694 and #696 too. However I didn't mention them, as I am considering to remove the relevant code. ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2006-11-23 06:56 Message: Logged In: NO Hi! Does this mean that the bug "SGML output fails with pdflatex" will also be solved? Cheers Danai SAE-HAN ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=705&group_id=106

1 0

Re: [NTG-pdftex] About the font_max limitation for vf_nf
by Thanh Han The 24 Nov '06

24 Nov '06

Hi, I took a closer look at the problem. vf_nf grows very fast because vf_nf = <number of vf fonts> * <number of tfm in each vf> We cannot reduce this, because the number of tfm inside a vf (let's call it the local tfm) is used to render the characters inside a vf. Hence pdftex must remember all local for all vf, which is the above number. However it seems reasonable to allow the limit to be much higher than font_max. I will submit a patch soon. Thanh On Wed, Nov 22, 2006 at 09:44:10PM +0800, Jie Luo wrote: > Hi, > > There is a GB.tex in the test.tar.bz2 which is a modification of GB.tex > in CJK package. This file can be compiled with TeXLive. When processing > this file with pdflatex, the vf_nf value reaches 1978 which is close to > the present font_max ( = 2000 ). I also attach the log files of another > two tex documents, hope to be helpful. > > Thanks, > > Jie > > Thanh Han The wrote: > >Hi, > > > >can you please send me a minimal test file so I can > >reproduce the problem? It is best to use fonts that are > >available in TeXLive so I can compile it. > > > >Thanks, > >Thanh > > > >On Wed, Nov 22, 2006 at 05:38:35PM +0800, Jie Luo wrote: > >>Hi Thanh, > >> > >>Thanh Han The wrote: > >>>Hi, > >>> > >>>I don't know whether this is a bug or not, unless I can > >>>reproduce the behaviour. You can verify by checking how many > >>>tfm fonts are opened by pdftex. If the total number of tfm > >>>fonts is much less than vf_nf, then it's likely a bug. > >>>However there are a few things to consider: > >>> > >>>- tex (and hence pdftex) loads the same tfm for different > >>> sizes, ef \font\f=cmr10 and \font\f=cmr10 at 12pt will > >>> load the tfm twice. > >>> > >>>- the same applies for vf. In the above example, if cmr10 is > >>> a virtual font containing 2 tfm, the number of loaded > >>> fonts will be 4. So you get the idea how quick it grows. > >>> > >>> > >>>You can use the script I attached to see which fonts have > >>>been opened during a tex run. Usage: > >>> > >>>,-------- > >>>| list-tex-files pdftex foo.tex > >>>`-------- > >>> > >>>It will run pdftex and saves the list of opened files into a > >>>temporary file. > >>> > >>>HTH, > >>>Thanh > >> > >>I did some tests using this script. > >> > >>GB.tex > >>vf_nf = 3114 > >>opened tfm files with pdflatex = 408 > >>opened tfm files with latex = 59 > >> > >>book.tex > >>vf_nf = 11834 > >>opened tfm files with pdflatex = 1075 > >>opened tfm files with latex = 364 > >> > >>So it seems that the vf_nf is about 10 times of the opened tfm files, > >>this maybe a bug. By the way, I do not have the list-tex-files.vim file, > >>is this a problem? > >> > >>Thanks, > >> > >>Jie > >> > >>> > >>>On Wed, Nov 22, 2006 at 01:12:56PM +0800, Jie Luo wrote: > >>>>Hi Thanh, > >>>> > >>>>When using pdflatex to processing tex documents contain more than two > >>>>Chinese GBK virtual fonts, pdflatex always failed with a divide by zero > >>>>error. I read the mail archive of pdftex list and find it said to be > >>>>related to the font_max limitation. I add some statement to debug this, > >>>>and find that the vf_nf value is about 2300 when using two Chinese GBK > >>>>virtual fonts. But when I use pdflatex to compile a book with about 250 > >>>>pages, the value of vf_nf is about 12000 with less than 100 type1 fonts > >>>>embedded in the pdf file. Is there any problem with the vf_nf? Or it is > >>>>the expected value. > >>>> > >>>> > >>>>Jie > >>> > >>>------------------------------------------------------------------------ > >>> > >>>#!/bin/sh > >>> > >>>if test "x$1" = x; then > >>> echo Usage: "$0 <tex command>" > >>> echo Example: "$0 latex myfile" > >>> exit 1 > >>>fi > >>>export KPATHSEA_DEBUG=4 > >>>f=/tmp/kpof.$$.1 > >>> > >>>$* 2>$f > >>>vim -S ~/vim/list-tex-files.vim $f > >>>echo "List of opened files saved to $f" > >>> > >> > > >

3 5

status of pending bugs
by Thanh Han The 24 Nov '06

24 Nov '06

Hi, it seems that it's too late now to remove some extensions. Though it's trivial to do so regards coding, the impact might be undesired so it is better to do that after TL has been released. So at the meantime I will try to fix some of the pending bugs. Here is the current status: 692, 694: fixed 693: still trying 695: unlikely to be fixed, even in the future. 696: Harmut and I are working on this, we hope to fix it during the wekend. Thanh

1 0

[ pdftex-Patches-705 ] Patch to allow vf_nf grow dynamically
by noreply＠sarovar.org 23 Nov '06

23 Nov '06

Patches item #705, was opened at 2006-11-22 19:52 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=705&group_id=106 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: The Thanh Han (hanthethanh) Assigned to: Nobody (None) Summary: Patch to allow vf_nf grow dynamically Initial Comment: This patch allows the array vf_e_fnts and vf_i_fnts grow dynamically, instead of having fixed size font_max as currently. ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2006-11-23 07:18 Message: Logged In: YES user_id=710 yes. this patch also contains a fix by Akira the segfault bug (one line added) and a fix for bug #692 (another line). It's not hard to fix bug #694 and #696 too. However I didn't mention them, as I am considering to remove the relevant code. ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2006-11-23 01:26 Message: Logged In: NO Hi! Does this mean that the bug "SGML output fails with pdflatex" will also be solved? Cheers Danai SAE-HAN ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=705&group_id=106

1 0

[ pdftex-Patches-705 ] Patch to allow vf_nf grow dynamically
by noreply＠sarovar.org 23 Nov '06

23 Nov '06

Patches item #705, was opened at 2006-11-23 01:22 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=705&group_id=106 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: The Thanh Han (hanthethanh) Assigned to: Nobody (None) Summary: Patch to allow vf_nf grow dynamically Initial Comment: This patch allows the array vf_e_fnts and vf_i_fnts grow dynamically, instead of having fixed size font_max as currently. ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2006-11-23 06:56 Message: Logged In: NO Hi! Does this mean that the bug "SGML output fails with pdflatex" will also be solved? Cheers Danai SAE-HAN ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=705&group_id=106

1 0

[ pdftex-Patches-705 ] Patch to allow vf_nf grow dynamically
by noreply＠sarovar.org 22 Nov '06

22 Nov '06

Patches item #705, was opened at 2006-11-22 19:52 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=705&group_id=106 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: The Thanh Han (hanthethanh) Assigned to: Nobody (None) Summary: Patch to allow vf_nf grow dynamically Initial Comment: This patch allows the array vf_e_fnts and vf_i_fnts grow dynamically, instead of having fixed size font_max as currently. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=705&group_id=106

1 0

removal of some extensions -- yes or no?
by Thanh Han The 22 Nov '06

22 Nov '06

Dear list, I am considering to remove some extensions I added to pdftex recently, as it's hard to make them work reliably, and they also seem little useful. In short they are: ,-------- | \pdfadjustinterwordglue, \knbscode, \stbscode, \shbscode: | adjust the interglue space according to the charater before | the glue | | \pdfprependkern, \knbccode: auto-insertion of a kern before a char | | \pdfappendkern, \knaccode: auto-insertion of a kern after a char `-------- Before I make a decision, I would like to listen to other opinions. So please let me know what you think of this. Thanks, Thanh

1 0

Re: [NTG-pdftex] [ pdftex-Bugs-695 ] Confusion when changing kerning settings within a paragraph
by Thanh Han The 21 Nov '06

21 Nov '06

Hi Hans, removing those features is trivial. The question is: - is it worthwhile to have them, at least with some limitations? - are they already used and hence removing them can cause trouble? AFAIK only Robert Schlicht and Ulrich Dirr have been playing with them a little bit, but nobody has made any use of those in serious work. Please correct me if I am wrong. Of course I am happy to play with those features when luatex is ready for that. Thanh On Sun, Nov 19, 2006 at 11:07:38PM +0100, Hans Hagen wrote: > Hi Thanh, > >I think it was not a good decision to introduce those new > >features, as they touch a very sensitive area of tex and > >it's hard to get them right. I wonder whether it is better > >to discard them all. > > > removing them is tricky since they may be in use already but don't spend to > much time on fixing things that are hard to fix in current tex; once luatex > is in a state where fontdata has no longer the global properties and where > we can have more control over font related featurss, you can probably > rewrite most of the code in a cleaner way > Hans > > > ----------------------------------------------------------------- > Hans Hagen | PRAGMA ADE > Ridderstraat 27 | 8061 GH Hasselt | The Netherlands > tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com > | www.pragma-pod.nl > ----------------------------------------------------------------- >

4 3

Re: [NTG-pdftex] [ pdftex-Bugs-695 ] Confusion when changing kerning settings within a paragraph
by Thanh Han The 19 Nov '06

19 Nov '06

I think it was not a good decision to introduce those new features, as they touch a very sensitive area of tex and it's hard to get them right. I wonder whether it is better to discard them all. Thanh On Wed, Nov 15, 2006 at 06:46:26AM +0530, noreply(a)sarovar.org wrote: > Bugs item #695, was opened at 2006-11-15 01:16 > You can respond by visiting: > http://sarovar.org/tracker/?func=detail%26atid=493%26aid=695%26group_id=106 > > Category: None > Group: None > Status: Open > Resolution: None > Priority: 5 > Submitted By: Robert (schlcht) > Assigned to: Nobody (None) > Summary: Confusion when changing kerning settings within a paragraph > > Initial Comment: > Extra kerning now has this nasty, unreliable kind of > paragraph scope, so that whether or not extra kerning > will be applied depends on whether tex needs to > hyphenate the paragraph, and whether a word contains a > discretionary. > (Same as for \pdfnoligatures [see discussion in feature > req 385], for which this may be an acceptable > limitation, since it has global scope, anyway. However, > I don't consider it acceptable for the kerning feature. > Think of language-dependant settings, for example.) > > \hsize 7cm > \pdfadjustspacing0 > \knaccode\font`s=500 > \knbccode\font`s=500 > \pdfappendkern1 \pdfprependkern1 > > nasty testing nasty testing nasty testing nasty testing > nasty testing > > nasty testing nasty testing nasty testing nasty testing > nasty testing > \pdfappendkern0 \pdfprependkern0 > nasty testing nasty testing nasty testing nasty testing > nasty testing > > \bye > > > ---------------------------------------------------------------------- > > You can respond by visiting: > http://sarovar.org/tracker/?func=detail%26atid=493%26aid=695%26group_id=106 > _______________________________________________ > ntg-pdftex mailing list > ntg-pdftex(a)ntg.nl > http://www.ntg.nl/mailman/listinfo/ntg-pdftex

3 2

[ pdftex-Bugs-692 ] Amount of extra kerning is wrong/has changed
by noreply＠sarovar.org 19 Nov '06

19 Nov '06

Bugs item #692, was opened at 2006-11-15 01:14 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=692&group_id=106 Category: hz Group: v1.40.0 Status: Open Resolution: Accepted Priority: 5 Submitted By: Robert (schlcht) Assigned to: The Thanh Han (hanthethanh) Summary: Amount of extra kerning is wrong/has changed Initial Comment: With \kn[ab]ccode=1000 a kern of 1em should be inserted. (Here, it's 2.32pt:) \tracingoutput1 \showboxdepth\maxdimen \showboxbreadth\maxdimen \pdfappendkern1 \pdfprependkern1 \knaccode\font`y=1000 \knbccode\font`y=1000 xyx \bye ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2006-11-19 10:10 Message: Logged In: YES user_id=710 This bug is caused by missing of declaration of k inside the function get_auto_kern, hence the global variable k is taken with wrong type (eight_bits). ---------------------------------------------------------------------- Comment By: Robert (schlcht) Date: 2006-11-17 15:12 Message: Logged In: YES user_id=2217 In fact, the kerning amount wraps at a kerning code of 256: \tracingoutput1 \showboxbreadth\maxdimen \pdfappendkern1 \knaccode\font`y=255 y % 2.55pt \knaccode\font`y=257 y % 0.01pt \knaccode\font`y=513 y % 0.01pt \bye ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=692&group_id=106

1 0

looking for Jochen Skupin
by Vit Zyka 17 Nov '06

17 Nov '06

Sorry for a bit off-topic. We are looking for: Jochen Skupin (jochen.skupin(a)uni-bremen.de) the author of pdfanim.sty package. Rober Marik significantly improved Jochen's package and he would like to CTANize/maintain this upgrade. The problem is that the e-mail above is deaf. Can somebody help to contact him, please? Thanks Vit Zyka

2 1

[ pdftex-Bugs-692 ] Amount of extra kerning is wrong/has changed
by noreply＠sarovar.org 17 Nov '06

17 Nov '06

Bugs item #692, was opened at 2006-11-15 01:14 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=692&group_id=106 Category: hz Group: v1.40.0 Status: Open Resolution: Accepted Priority: 5 Submitted By: Robert (schlcht) Assigned to: The Thanh Han (hanthethanh) Summary: Amount of extra kerning is wrong/has changed Initial Comment: With \kn[ab]ccode=1000 a kern of 1em should be inserted. (Here, it's 2.32pt:) \tracingoutput1 \showboxdepth\maxdimen \showboxbreadth\maxdimen \pdfappendkern1 \pdfprependkern1 \knaccode\font`y=1000 \knbccode\font`y=1000 xyx \bye ---------------------------------------------------------------------- >Comment By: Robert (schlcht) Date: 2006-11-17 15:12 Message: Logged In: YES user_id=2217 In fact, the kerning amount wraps at a kerning code of 256: \tracingoutput1 \showboxbreadth\maxdimen \pdfappendkern1 \knaccode\font`y=255 y % 2.55pt \knaccode\font`y=257 y % 0.01pt \knaccode\font`y=513 y % 0.01pt \bye ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=692&group_id=106

1 0

Re: [NTG-pdftex] [pdftex] SGML output fails with pdflatex
by Thanh Han The 16 Nov '06

16 Nov '06

On Thu, Nov 16, 2006 at 02:39:36PM +0100, Taco Hoekwater wrote: > > > Thanh Han The wrote: > >Hi, > > > >yes this seems to be the right cause of the bug. I was > >silent because I cannot reproduce the bug with the test > >file sent by Werner. The previous case seems irrelevant, as > >font_used[f] is already checked inside pdf_begin_string, ie > >whenever non-virtual char is written out. > > Then it looks like font_max must be raised again in the > change file, yes? no need to do so, it's configurable in texmf.cnf Regards, Thanh

2 1

Re: [NTG-pdftex] [pdftex] SGML output fails with pdflatex
by Thanh Han The 16 Nov '06

16 Nov '06

ah sorry, I overlooked. Yes it must be changed in the change file. Thanh On Thu, Nov 16, 2006 at 02:44:03PM +0100, The Thanh Han wrote: > On Thu, Nov 16, 2006 at 02:39:36PM +0100, Taco Hoekwater wrote: > > > > > > Thanh Han The wrote: > > >Hi, > > > > > >yes this seems to be the right cause of the bug. I was > > >silent because I cannot reproduce the bug with the test > > >file sent by Werner. The previous case seems irrelevant, as > > >font_used[f] is already checked inside pdf_begin_string, ie > > >whenever non-virtual char is written out. > > > > Then it looks like font_max must be raised again in the > > change file, yes? > > no need to do so, it's configurable in texmf.cnf > > Regards, > Thanh

1 0

Re: [NTG-pdftex] [pdftex] SGML output fails with pdflatex
by Thanh Han The 16 Nov '06

16 Nov '06

Hi, yes this seems to be the right cause of the bug. I was silent because I cannot reproduce the bug with the test file sent by Werner. The previous case seems irrelevant, as font_used[f] is already checked inside pdf_begin_string, ie whenever non-virtual char is written out. Regards, Thanh On Thu, Nov 16, 2006 at 10:38:13AM +0100, Taco Hoekwater wrote: > I think I have found it from checking up your hint about font_used[] > in the debugger: > > The arrays vf_i_fnts[] and vf_e_fnts[] are alloc as size font_max, but > their indexes can easily overflow that because a vf font can contain > more than one base font. > > I've added two cases of > > if vf_nf>font_max then > overflow("virtual fonts",font_max); > > right after the two occurrences of increments of vf_nf in pdftex.web, > and now I get: > > ! TeX capacity exceeded, sorry [virtual fonts=2000]. > > Cheers, > Taco > > > > _______________________________________________ > ntg-pdftex mailing list > ntg-pdftex(a)ntg.nl > http://www.ntg.nl/mailman/listinfo/ntg-pdftex

2 1

Re: [NTG-pdftex] [pdftex] SGML output fails with pdflatex
by Akira Kakuto 16 Nov '06

16 Nov '06

> > It is an oversight, the problem is that the global |f| is of the wrong > > type. In pdftex.web, > > > > @@ -13795,7 +13795,8 @@ > > @!dead_cycles:integer; {recent outputs that didn't ship anything out} > > @!doing_leaders:boolean; {are we inside a leader box?} > > @# > > -@!c,@!f:quarterword; {character and font in current |char_node|} > > +@!c:quarterword; {character in current |char_node|} > > +@!f:internal_font_number; {font in current |char_node|} > > @!rule_ht,@!rule_dp,@!rule_wd:scaled; {size of current rule being output} > > @!g:pointer; {current glue specification} > > @!lq,@!lr:integer; {quantities used in calculations for leaders} > > > > Should fix this problem as well as any potentially still lurking similar > > problems. Is it special to Debian? In 1.40.0 beta, I think it does not remain in the final pdftex.p since in tex.ch, and thus in pdftex.ch, there are lines @x @!c,@!f:quarterword; {character and font in current |char_node|} @y {character and font in current |char_node|} @!c:quarterword; @!f:internal_font_number; @z Best regards, Akira

4 5

Re: [NTG-pdftex] [pdftex] SGML output fails with pdflatex
by Akira Kakuto 16 Nov '06

16 Nov '06

> > vf_replace_z; > > save_vf := f; > > f := vf_i_fnts[vf_default_font[save_vf]]; > > + if not font_used[f] then > > + pdf_init_font(f); > > save_v := cur_v; > > save_h := cur_h; > > w := 0; x := 0; y := 0; z := 0; > > Is that a typo of font_used(f) ? > I didn't yet try in pdfTeX, but tried and failed > in luaTeX ( succeeded by changing font_used[f] ---> font_used(f) ). Sorry, I've noticed that luaTeX and pdfTeX is different! Thanks, Akira

1 0