July 2007 - ntg-pdftex - NTG Mailing Lists

Re: [NTG-pdftex] 1.40.4 incoming
by Akira Kakuto 09 Jul '07

09 Jul '07

Hi Martin, > - 746 PromptFileName The latest version of 746 (retry), changed by Heiko himself, is the following. This problem is related to all Web2C, so I've attached the corresponding changes for Aleph and Omega. Please check in these changes also to the head of TeXLive repository if these are ok. Best regards, Akira *** tex.ch.org 2006-12-19 02:35:49.000000000 +0100 --- tex.ch 2007-03-07 17:08:49.000000000 +0100 *************** *** 2210,2221 **** --- 2210,2229 ---- @y var k:0..buf_size; {index into |buffer|} @!saved_cur_name:str_number; {to catch empty terminal input} + @!saved_cur_ext:str_number; {to catch empty terminal input} + @!saved_cur_area:str_number; {to catch empty terminal input} @z @x [29.530] l.10252 - prompt_file_name: No default extension is TeX input file. if e=".tex" then show_context; @y if (e=".tex") or (e="") then show_context; + print_ln; print("(Retry if file name is empty or CTRL-D to exit."); + if (e<>"") then + begin + print(" Default file extension is `"); print(e); print("'"); + end; + print(")"); print_ln; @z @x [29.530] l.10258 - prompt_file_name: prevent empty filenames. *************** *** 2223,2231 **** if cur_ext="" then cur_ext:=e; @y saved_cur_name:=cur_name; clear_terminal; prompt_input(": "); @<Scan file name in the buffer@>; ! if cur_ext="" then cur_ext:=e; ! if length(cur_name)=0 then cur_name:=saved_cur_name; @z @x [29.532] l.10263 - avoid conflict, `logname' in <unistd.h> on some systems. --- 2231,2247 ---- if cur_ext="" then cur_ext:=e; @y saved_cur_name:=cur_name; + saved_cur_ext:=cur_ext; + saved_cur_area:=cur_area; clear_terminal; prompt_input(": "); @<Scan file name in the buffer@>; ! if (length(cur_name)=0) and (cur_ext="") and (cur_area="") then ! begin ! cur_name:=saved_cur_name; ! cur_ext:=saved_cur_ext; ! cur_area:=saved_cur_area; ! end ! else ! if cur_ext="" then cur_ext:=e; @z @x [29.532] l.10263 - avoid conflict, `logname' in <unistd.h> on some systems. diff -u alephdir-orig/com16bit-rc2.ch alephdir/com16bit-rc2.ch --- alephdir-orig/com16bit-rc2.ch Tue Dec 19 10:35:50 2006 +++ alephdir/com16bit-rc2.ch Sat Mar 17 20:41:09 2007 @@ -1349,12 +1349,20 @@ @y var k:0..buf_size; {index into |buffer|} @!saved_cur_name:str_number; {to catch empty terminal input} +@!saved_cur_ext:str_number; {to catch empty terminal input} +@!saved_cur_area:str_number; {to catch empty terminal input} @z @x [29.530] l.10252 - prompt_file_name: No default extension is TeX input file. if e=".tex" then show_context; @y if (e=".tex") or (e="") then show_context; +print_ln; print("(Retry if file name is empty or CTRL-D to exit."); +if (e<>"") then + begin + print(" Default file extension is `"); print(e); print("'"); + end; +print(")"); print_ln; @z @x [29.530] l.10258 - prompt_file_name: prevent empty filenames. @@ -1362,9 +1370,17 @@ if cur_ext="" then cur_ext:=e; @y saved_cur_name:=cur_name; +saved_cur_ext:=cur_ext; +saved_cur_area:=cur_area; clear_terminal; prompt_input(": "); @<Scan file name in the buffer@>; -if cur_ext="" then cur_ext:=e; -if length(cur_name)=0 then cur_name:=saved_cur_name; +if (length(cur_name)=0) and (cur_ext="") and (cur_area="") then + begin + cur_name:=saved_cur_name; + cur_ext:=saved_cur_ext; + cur_area:=saved_cur_area; + end +else + if cur_ext="" then cur_ext:=e; @z @x [29.532] l.10263 - avoid conflict, `logname' in <unistd.h> on some systems. diff -u omegadir-orig/com16bit.ch omegadir/com16bit.ch --- omegadir-orig/com16bit.ch Tue Dec 19 10:35:50 2006 +++ omegadir/com16bit.ch Sat Mar 17 20:44:41 2007 @@ -1348,12 +1348,20 @@ @y var k:0..buf_size; {index into |buffer|} @!saved_cur_name:str_number; {to catch empty terminal input} +@!saved_cur_ext:str_number; {to catch empty terminal input} +@!saved_cur_area:str_number; {to catch empty terminal input} @z @x [29.530] l.10252 - prompt_file_name: No default extension is TeX input file. if e=".tex" then show_context; @y if (e=".tex") or (e="") then show_context; +print_ln; print("(Retry if file name is empty or CTRL-D to exit."); +if (e<>"") then + begin + print(" Default file extension is `"); print(e); print("'"); + end; +print(")"); print_ln; @z @x [29.530] l.10258 - prompt_file_name: prevent empty filenames. @@ -1361,9 +1369,17 @@ if cur_ext="" then cur_ext:=e; @y saved_cur_name:=cur_name; +saved_cur_ext:=cur_ext; +saved_cur_area:=cur_area; clear_terminal; prompt_input(": "); @<Scan file name in the buffer@>; -if cur_ext="" then cur_ext:=e; -if length(cur_name)=0 then cur_name:=saved_cur_name; +if (length(cur_name)=0) and (cur_ext="") and (cur_area="") then + begin + cur_name:=saved_cur_name; + cur_ext:=saved_cur_ext; + cur_area:=saved_cur_area; + end +else + if cur_ext="" then cur_ext:=e; @z @x [29.532] l.10263 - avoid conflict, `logname' in <unistd.h> on some systems.

4 6

[ pdftex-Patches-746 ] Patch PromptFileName
by noreply＠sarovar.org 09 Jul '07

09 Jul '07

Patches item #746, was opened at 2007-03-07 17:41 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=746&group_id=106 Category: User interaction Group: v1.40.0 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Heiko Oberdiek (oberdiek) Assigned to: Martin Schröder (oneiros) Summary: Patch PromptFileName Initial Comment: Subject: Patch PromptFileName Date: 2007/03/07 Author: Heiko Oberdiek The patches are based on pdfTeX 1.40.3 There is some discussion in the tex-live list: List: tex-live(a)tug.org Date: March 2007 Subject: Bug in TexLive 2005 and 2007? Non-writable aux-file If TeX asks for a file name, what action should be taken, if the user doesn't provide a file name? The current behaviour has changed from Web2C 7.5.2 to 7.5.6 and is quite impredictible: * Append some default extension if file extension is not given. * Use previous file name part, if this part is empty. Sometimes this behaves as "retry action" by chance, sometimes a source file gets overwritten. Two patches are provided that implement alternative actions: * Retry.diff If the user doesn't specify a file name, then the whole previous file name is used including the area and extension parts. * Abort.diff If the user doesn't specify a file name, then the job is aborted. Unhappily Ctrl-C (or Ctrl-D) have only a retarded effect after the file name is used again (and eventually causing harm). This is a clean way to end the job even if there isn't a valid file name to provide. Both files patches web2c/texk/tex.ch. Of course they cannot be used at the same time. And both patches also show the default name extension, when the user is prompted for a file name. Have fun, Heiko <oberdiek(a)uni-freiburg.de> ---------------------------------------------------------------------- >Comment By: Martin Schröder (oneiros) Date: 2007-07-09 12:23 Message: Logged In: YES user_id=421 Retry.diff will be included in the next version (1.40.4/1.50.0). ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-03-10 23:57 Message: Logged In: YES user_id=421 Both patches are interesting, but we should wait for further discussion on tex-implementors etc. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=746&group_id=106

1 0

Re: [NTG-pdftex] 1.40.4 incoming
by Thanh Han The 09 Jul '07

09 Jul '07

On Sun, Jul 08, 2007 at 10:52:24PM +0200, Thanh Han The wrote: > On 07.07.2007 15:14, Martin Schr�der wrote: > >Please test and tell me what I've forgotten. :-) > > what about patch #813? It's rather straightforward and > handy. and also #812, if there is no further objection. Thanh

3 5

Re: [NTG-pdftex] 1.40.4 incoming
by Akira Kakuto 09 Jul '07

09 Jul '07

> > *** tex.ch.org 2006-12-19 02:35:49.000000000 +0100 > > --- tex.ch 2007-03-07 17:08:49.000000000 +0100 > > Note that tex.ch has been changed since 2006-12-19. > Therefore you will need some manual work, sorry. It was an unnecessary fear. I've checked that the patch is still ok. Best regards, Akira

1 0

Re: [NTG-pdftex] 1.40.4 incoming
by Akira Kakuto 09 Jul '07

09 Jul '07

Hi Martin, > *** tex.ch.org 2006-12-19 02:35:49.000000000 +0100 > --- tex.ch 2007-03-07 17:08:49.000000000 +0100 Note that tex.ch has been changed since 2006-12-19. Therefore you will need some manual work, sorry. Best regards, Akira

1 0

[ pdftex-Patches-811 ] Patch to change warning mesage for conflicting font attributes (given by \pdffontattr)
by noreply＠sarovar.org 09 Jul '07

09 Jul '07

Patches item #811, was opened at 2007-06-23 19:04 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=811&group_id=106 Category: Fonts Group: v1.50.0 Status: Closed Resolution: Accepted Priority: 5 Submitted By: The Thanh Han (hanthethanh) Assigned to: Martin Schröder (oneiros) Summary: Patch to change warning mesage for conflicting font attributes (given by \pdffontattr) Initial Comment: This is a tiny patch to change the warning message for conflicting font attributes (as given by \pdffontattr), to make it clearer what is going on. ---------------------------------------------------------------------- >Comment By: Martin Schröder (oneiros) Date: 2007-07-09 00:12 Message: Logged In: YES user_id=421 This was already included in the fix for #721. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-07-09 00:05 Message: Logged In: YES user_id=421 This patch will be included in the upcoming 1.50 ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=811&group_id=106

1 0

[ pdftex-Patches-811 ] Patch to change warning mesage for conflicting font attributes (given by \pdffontattr)
by noreply＠sarovar.org 09 Jul '07

09 Jul '07

Patches item #811, was opened at 2007-06-23 19:04 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=811&group_id=106 Category: Fonts Group: v1.50.0 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: The Thanh Han (hanthethanh) Assigned to: Martin Schröder (oneiros) Summary: Patch to change warning mesage for conflicting font attributes (given by \pdffontattr) Initial Comment: This is a tiny patch to change the warning message for conflicting font attributes (as given by \pdffontattr), to make it clearer what is going on. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-07-09 00:05 Message: Logged In: YES user_id=421 This patch will be included in the upcoming 1.50 ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=811&group_id=106

1 0

[ pdftex-Patches-813 ] new primitive \pdfinclusioncopyfonts
by noreply＠sarovar.org 09 Jul '07

09 Jul '07

Patches item #813, was opened at 2007-06-23 19:28 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=813&group_id=106 Category: Fonts Group: v1.50.0 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: The Thanh Han (hanthethanh) Assigned to: Hartmut Henkel (hhenkel) Summary: new primitive \pdfinclusioncopyfonts Initial Comment: this is a replacement for \pdfreplacefont, with the opposite semantics. When this is set, fonts from included pdfs are always copied. This is useful to prevent pdftex from replacing fonts in included pdfs, without messing around with map files. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-07-09 00:00 Message: Logged In: YES user_id=421 This patch will be included in the upcoming 1.50 ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=813&group_id=106

1 0

[ pdftex-Patches-812 ] added \pdfkeeplinedimen primitive
by noreply＠sarovar.org 08 Jul '07

08 Jul '07

Patches item #812, was opened at 2007-06-23 19:23 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=812&group_id=106 Category: Primitives Group: v1.50.0 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: The Thanh Han (hanthethanh) Assigned to: Hartmut Henkel (hhenkel) Summary: added \pdfkeeplinedimen primitive Initial Comment: This patch introduces a new primitive \pdfkeepdimenline, which is an addon to bring some more flexibity to the existing \pdflastlinedepth, \pdffirstlineheight, \pdfeachlinedepth and \pdfeachlineheight primitives. Those primitives are set to 0 by default, and they take effect only if the user sets them to a non-zero value (as one can guess from their names, they fix line dimensions of a paragraph). The issue with those primitives is that it's impossible to use them with 0, as this value means "don't change line dimens". So this patch introduces \pdfkeepdimenline, a dimen register keeping the value for "don't change line dimens". By default all are set to 0, so the default behaviour is unchanged. For example, to set depth of each line after line breaking to zero, one can say: \pdfkeeplinedimen=\maxdimen \pdfeachlineheight=\pdfkeeplinedimen \pdffirstlineheight=\pdfkeeplinedimen \pdflastlinedepth=\pdfkeeplinedimen \pdfeachlinedepth=0pt Testing/comments welcome. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-07-08 23:52 Message: Logged In: YES user_id=421 This patch will be included in the upcoming 1.50 ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-06-29 13:02 Message: Logged In: YES user_id=710 here is another patch that introduces \pdfignoreddimen as Taco suggested. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-06-24 10:41 Message: Logged In: YES user_id=710 sounds good to me. ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2007-06-24 10:28 Message: Logged In: YES user_id=1608 I see an advantage in having a configurable parameter over the arbitrary constant that \prevdepth currently uses. But if that is the case, it makes sense to apply it to \prevdepth as well. So how about \pdfignoreddimen instead, that defaults to -1000pt, and is also used by \prevdepth ? ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-06-24 10:26 Message: Logged In: YES user_id=710 another patch uploaded, so the pdftex team can choose between them. Hope to make Nobody (None) happy. ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2007-06-23 19:29 Message: Logged In: NO This is completely clunky and awkward. Instead of having some magic variable which changes the meaning of _all_ addresses here, how about just using \prevdepth's default for "no change", namely -1000pt? ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=812&group_id=106

1 0

[ pdftex-Bugs-747 ] \letterspacefont and \pdffontexpand, again
by noreply＠sarovar.org 08 Jul '07

08 Jul '07

Bugs item #747, was opened at 2007-03-09 04:09 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=747&group_id=106 Category: hz Group: v1.40.1 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Robert (schlcht) Assigned to: The Thanh Han (hanthethanh) Summary: \letterspacefont and \pdffontexpand, again Initial Comment: When expanding a letterspaced font, the base font will be expanded, too, resulting in the error `font has been expanded with different parameters' when the base font is expanded again: \letterspacefont\lsfont\font 100 \pdffontexpand\lsfont 20 20 5 autoexpand \pdffontexpand\font 20 20 5 autoexpand Z\bye ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-07-08 23:40 Message: Logged In: YES user_id=421 A fix for this will be included in the next release (1.40.4/1.50.0). ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-07-08 22:08 Message: Logged In: YES user_id=710 it seems that Martin refered to stable as the stable branch in svn, not the latest stable release 1.40.3. I checked the patch again, it's good. Thanks. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-07-08 21:45 Message: Logged In: YES user_id=710 the patch bugfix747-5.diff was generated against pdftex-1.40.3 sources as it is at sarovar. I have just verified it again by downloading the tarball from sarovar, unpack it and try the patch. No complain at all, while with bug747-6.diff I got some warnings and one rejection: patching file pdftex.web Hunk #4 succeeded at 9528 (offset -1 lines). Hunk #5 succeeded at 13180 (offset -7 lines). Hunk #6 succeeded at 16751 (offset 2 lines). Hunk #7 succeeded at 17026 (offset 2 lines). Hunk #8 succeeded at 17037 (offset 2 lines). Hunk #9 succeeded at 17171 (offset 41 lines). Hunk #10 succeeded at 17193 (offset 41 lines). Hunk #11 succeeded at 17201 (offset 41 lines). Hunk #12 succeeded at 17211 (offset 41 lines). Hunk #13 FAILED at 17241. Hunk #14 succeeded at 17379 (offset 24 lines). Hunk #15 succeeded at 17644 (offset 40 lines). Hunk #16 succeeded at 19958 (offset 31 lines). Hunk #17 succeeded at 20037 (offset 31 lines). Hunk #18 succeeded at 20189 (offset 21 lines). Hunk #19 succeeded at 30880 (offset 19 lines). Hunk #20 succeeded at 31623 (offset 19 lines). 1 out of 20 hunks FAILED -- saving rejects to file pdftex.web.rej ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-07-08 19:17 Message: Logged In: YES user_id=421 The patch had one rejected hunk against stable and current. A working patch is attached; please check. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-07-04 10:13 Message: Logged In: YES user_id=710 patch updated again. Disable \pdfcopyfont for expanded and letterspaced fonts. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-07-03 23:21 Message: Logged In: YES user_id=710 I didn't consider the situation when an expanded font is copied. It seems pretty much of work is needed to get it right, so probably it is easier to disable \pdfcopyfont for expanded (and letterspaced) fonts. ---------------------------------------------------------------------- Comment By: Robert (schlcht) Date: 2007-07-03 19:39 Message: Logged In: YES user_id=2217 Thanks. Letterspacing+expansion works fine now, and \pdfcopyfont is also useful. I gather an expanded font cannot be copied again, right? (Not that I would deem this necessary.) The messages from the following are a bit weird: \tracingonline1 \font\f=cmr10 \pdfcopyfont\fA\f \pdffontexpand\fA 10 10 5 autoexpand \fA ABC \pdfcopyfont\fB\fA \fB ABC \bye ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-06-30 18:25 Message: Logged In: YES user_id=710 ah, sorry, here it is. ---------------------------------------------------------------------- Comment By: Robert (schlcht) Date: 2007-06-30 18:12 Message: Logged In: YES user_id=2217 the patch is missing... ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-06-29 17:58 Message: Logged In: YES user_id=710 patch updated again. I have tested it with the following: \font\f=cmr10 \pdfcopyfont\fA=\f \letterspacefont\fB=\fA 100 \pdffontexpand\fB 30 30 5 autoexpand \fB \input tufte.tex and it seems to work. But the following doesn't: \letterspacefont\fC=\f 100 \pdfcopyfont\fD=\fC \pdffontexpand\fD 30 30 5 autoexpand probably it's possible with some more effort to make the latter case work too, but it doesn't seem needed. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-06-29 15:32 Message: Logged In: YES user_id=710 patch deleted. Needs more testing. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-06-29 11:56 Message: Logged In: YES user_id=710 sorry, I didn't test it carefully enough. Here is another attempt (tested with the microtype manual). ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-06-29 10:52 Message: Logged In: YES user_id=421 Taco, the new_font_type -> real_font_type is from the fix for bug #722. We need an svn... :-( ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2007-06-29 09:22 Message: Logged In: YES user_id=1608 On my (fairly) clean sources, one hunk is rejected because of this: else begin if pdf_font_type[f] <> new_font_type then pdf_warning("font expansion", "font should be expanded before its first use", true, true); end; My pdftex.web uses pdf_font_type[f] = real_font_type in that test. I fixed the hunk, but I also get a crash on Robert's test file. ---------------------------------------------------------------------- Comment By: Robert (schlcht) Date: 2007-06-29 01:17 Message: Logged In: YES user_id=2217 Now this yields a core dump with: \pdfadjustspacing2 \pdffontexpand\font 20 20 5 autoexpand \hsize10em Lorem ipsum dolor sit amet, \bye (unless I've messed up pdftex.web with all them patches) ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-06-28 22:17 Message: Logged In: YES user_id=710 here is another patch, which introduces \pdfcopyfont. Example: \letterspacefont\lsfont\font 100 \pdfcopyfont\lsxfont\lsfont \pdffontexpand\lsxfont 20 20 5 autoexpand This patch also fixed a bug in expanding local font from virtual fonts: font shrinking didn't work. Big thanks to Robert for help with testing. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-06-28 20:42 Message: Logged In: YES user_id=710 expanding a letterspaced fonts always implies that the base font is expanded. In other words, it's impossible *not* to expand the base font when expanding a letterspaced font. thanks for further testing. It looks like a bug in checking font expansion spec. fwiw, font stretch limit is always fixed to [0..1000] and font shrink limit to [0..500]. Thus giving a negative value has the same effect like giving 0. I will play with \copyfont to see if it helps. ---------------------------------------------------------------------- Comment By: Robert (schlcht) Date: 2007-06-28 16:01 Message: Logged In: YES user_id=2217 If we can get rid of the error message, I think it can be left at that. Mind you, the problem is not how to expand a letterspaced font but how to *not* expand the base font when expanding a letterspaced font. That expanding a letterspaced font results in expansion of the base font can be documented as a feature, IMO. Here are some more clues: The error message seems to be related to the sign of the stretch parameter. First of all, with \letterspacefont\lsfont\font 100 \pdffontexpand\lsfont 20 20 5 autoexpand the base font will be expanded, however it will never be shrunk. Then, \letterspacefont\lsfont\font 100 \pdffontexpand\lsfont 20 20 5 autoexpand \pdffontexpand\font 20 -20 5 autoexpand doesn't yield an error. Neither does: \pdffontexpand\lsfont 20 -20 5 autoexpand \pdffontexpand\font 20 -20 5 autoexpand However, here comes the error again: \pdffontexpand\lsfont 20 -20 5 autoexpand \pdffontexpand\font 20 20 5 autoexpand If you expand the base font first, it's OK in any case, also with different signs. ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2007-06-28 09:37 Message: Logged In: YES user_id=1608 That sounds nice, I like it. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-06-28 08:45 Message: Logged In: YES user_id=710 I agree this is an ugly solution, which has its origin in a design mistake. However the problem here is not only how to deal with the error message, but the point is how to use font expansion with a letterspaced font. Please give it a thought so we can come up with an acceptable workaround. If we want everything to be clean, there are more things that have to be thrown away. what about this: have a primitive \copyfont which creates a copy of a font. Example: \letterspacefont\lsfont\font 100 \copyfont\lsxfont\lsfont \pdffontexpand\lsxfont 20 20 5 autoexpand ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2007-06-27 13:43 Message: Logged In: YES user_id=1608 If there is no clean way of solving the problem, I'd rather just document the error message as a feature. I find \pdfnewexpandfont very ugly (sorry Thanh). ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-06-24 12:46 Message: Logged In: YES user_id=710 here is a patch that introduces a new primitive \pdfnewexpandfont. Usage: \font\f=cmr10 \pdfnewexpandfont\fx \f 20 20 5 autoexpand Note that \pdfnewexpandfont generates \fx by loading a TFM corresponding to \f first, then applies font expansion in the same way like "\pdffontexpand\fx 20 20 5". So when \f is a font that doesn't have a corresponding TFM (for example, because it was generated in pdftex memory only), the above command won't work. In particular, the following doesn't work: \font\f=cmr10 \letterspacefont\lsfont\f 100 \pdfnewexpandfont\fx \lsfont 20 20 5 autoexpand since \lsfont doesn't have a corresponding TFM but was generated by \letterspacefont. To create a letterspaced+expanded font, one can use: \font\f=cmr10 \letterspacefont\fx\f 100 \pdffontexpand\fx 20 20 5 autoexpand things are gettting messy... sorry about that. Testing/comments welcome. ---------------------------------------------------------------------- Comment By: Robert (schlcht) Date: 2007-04-01 02:44 Message: Logged In: YES user_id=2217 Fine for me and microtype. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-03-31 11:52 Message: Logged In: YES user_id=710 either name is ok with me. We need a new pritimive to load a new font and expand it, since the current one doesn't load a new font and hence is making trouble. I would wait for a while to see how Robert sees it before making any change. ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2007-03-19 12:07 Message: Logged In: NO Hello, I do not think that \pdfexpandfont is a good name for a new primitive, as it is too easy to confuse with \pdffontexpand. What about \pdfexpandnewfont, as -- if I understand correctly -- a new font is loaded? Jonathan P.S: Thank you for creating pdfTeX! ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-03-10 21:18 Message: Logged In: YES user_id=710 Phil Taylor has a suggestion that seems great to me: introduce a new primitive \pdfexpandfont instead. How do you see it? ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-03-10 20:24 Message: Logged In: YES user_id=421 Forget that comment. Of course a change of \pdffontexpand has to be considered carefully. By you. :-) ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-03-10 20:22 Message: Logged In: YES user_id=421 No. It's an undocumented primitive. ;-) ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-03-09 18:28 Message: Logged In: YES user_id=710 sigh. A mistake when implementing the \pdffontexpand primitive: it should load a new font for expansion, instead of expanding a loaded font. Too late for change now? ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=747&group_id=106

1 0