- ntg-pdftex - NTG Mailing Lists

[ pdftex-Bugs-304 ] Names of expanded fonts not in log output
by noreply＠sarovar.org 15 Oct '05

15 Oct '05

Bugs item #304, was opened at 2005-03-02 17:25 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=304&group_id=106 Category: Fonts Group: v1.21a Status: Closed Resolution: Fixed Priority: 5 Submitted By: Robert (schlcht) Assigned to: Hartmut Henkel (hhenkel) Summary: Names of expanded fonts not in log output Initial Comment: When using font expansion, the log output will not contain the names of the expanded fonts but the null character instead (resp. ^^@). %------------------------------------- \pdfadjustspacing=2 \pdffontexpand\font 20 20 5 autoexpand \tracingoutput=1 test \parfillskip 0pt test \bye %------------------------------------- Regards, Robert. ---------------------------------------------------------------------- >Comment By: Robert (schlcht) Date: 2005-10-15 22:24 Message: Logged In: YES user_id=2217 If the font is not autoexpand'ed, its name will still not be written to the log file. (pdftex 1.30.3; same test file, without "autoexpand") Regards, Robert. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2005-05-12 15:05 Message: Logged In: YES user_id=421 This has been fixed in 1.30.0 ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2005-03-30 20:16 Message: Logged In: YES user_id=929 This patch is based of Thanh's change file showfont.ch, which he gave me during EuroTeX2005 (it's also included, renamed here to showfont-thanh.ch). Use showfont.ch for the patch. There is now a new integer variable \pdftracingfonts. It is zero by default, then we get a log like this (see robert050302.log): ...\tenrm t ...\tenrm (+20) e Without font expansion, this default should be compatible with TeX's original log output. If \pdftracingfonts is set to 1 (or greater), we get a more verbose log (see tst-304.log): ...\xivtt (cmtt10(a)14.0pt) t .\xivtt (cmtt10+20(a)14.0pt) e Seems to work with change file showfont.ch coming directly after after hz.ch. Patch only roughly tested with pdfetex, likely to give problems with pdfxtex, as the variable numbering might differ. Log format to be agreed upon... Regards, Hartmut ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=304&group_id=106

1 0

bug in pdfetex (re \immediate)?
by Vladimir Volovich 15 Oct '05

15 Oct '05

Hi! consider the following Plain TeX file: \immediate\immediate\openout1=test.out \immediate\write1 {line 1} \immediate\write1 {line 2} \immediate\closeout1 \bye (it was reduced from a real-life example). if i process it with vanilla TeX engine (i.e. not with pdfetex, but with TeX), you get what i expect: two lines are written to the file test.out, and there are no pages of output (no DVI file generated). however, if i process this file with pdfetex, i do not get what i would expect: instead, the lines are written to terminal, test.out is created and is empty, and there is also a 1-page PDF file generated. the bug goes away if i remove the second \immediate, but as i said this is a simplified example converted from a real-life usage. Best, v.

2 1

[ pdftex-Bugs-437 ] two \immediate cancel itself
by noreply＠sarovar.org 15 Oct '05

15 Oct '05

Bugs item #437, was opened at 2005-10-15 23:57 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=437&group_id=106 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Heiko Oberdiek (oberdiek) Assigned to: Nobody (None) Summary: two \immediate cancel itself Initial Comment: Hello, Vladimir Volovich found the following bug, I quote his bug report from the ntg-pdftex list here: > consider the following Plain TeX file: > > \immediate\immediate\openout1=test.out > \immediate\write1 {line 1} > \immediate\write1 {line 2} > \immediate\closeout1 > > \bye > > (it was reduced from a real-life example). > > if i process it with vanilla TeX engine (i.e. not > with pdfetex, but with TeX), you get what i expect: > two lines are written to the file test.out, and > there are no pages of output (no DVI file generated). > > however, if i process this file with pdfetex, i do > not get what i would expect: instead, the lines are > written to terminal, test.out is created and is > empty, and there is also a 1-page PDF file generated. > > the bug goes away if i remove the second \immediate, > but as i said this is a simplified example converted > from a real-life usage. It is indeed a bug: this is the original code of "Implement \immediate": | begin get_x_token; | if (cur_cmd=extension)and(cur_chr<=close_node) then | begin p:=tail; do_extension;{append a whatsit node} | out_what(tail); {do the action immediately} | flush_node_list(tail); tail:=p; link(p):=null; | end | else back_input; | end A token is read. If the token hears to \immediate, it is executed with the immediate setting. Otherwise the token is just put back. Now pdfTeX has more commands that obey \immediate: | begin get_x_token; | if cur_cmd=extension then begin | if cur_chr<=close_node then | begin <<original action>> end | else case cur_chr of | pdf_obj_code: begin <<...>> end; | pdf_xform_code: begin <<...>> end; | pdf_ximage_code: begin <<...>> end; | end; | endcases; | end | else | back_input; | end Cases: a) cur_cmd != extension --> nothing is changed (back_input) b) cur_cmd == extension && cur_chr <= close_node --> nothing is changed (original action) c) cur_cmd == extension && cur_chr in (pdf_{obj,xform,ximage}_code) --> new behaviour for pdfTeX d) cur_cmd == extension && cur_chr > close_node && cur_chr not in (pdf_{obj,xform,ximage}_code) --> no action Case d) is the bug. \immediate is an extension primitive with cur_chr > close_node. Thus the second \immediate is read, but then dropped. The effect is: \immediate\immediate\openout is same as \openout Instead of "no action" there should be "back_input". Before "endcases" the following line needs to be added: ... else case cur_chr of ... othercases back_input endcases; I have attachted a diff file for pdftexdir/pdftex.ch. Yours sincerely Heiko <oberdiek(a)uni-freiburg.de> ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=437&group_id=106

1 0

[ pdftex-Bugs-435 ] Wrong file name in error messages of image inclusion (readimage)
by noreply＠sarovar.org 14 Oct '05

14 Oct '05

Bugs item #435, was opened at 2005-10-15 01:21 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=435&group_id=106 Category: Image inclusion Group: None Status: Open Resolution: None Priority: 5 Submitted By: Heiko Oberdiek (oberdiek) Assigned to: Martin Schröder (oneiros) Summary: Wrong file name in error messages of image inclusion (readimage) Initial Comment: Hello, see the thread "Wrong search path for PDF/PNG/JPG files" (2005/10/14) in the pdftex mailing list. Wlodek Bzyl detected a bug regarding image inclusion: pdfTeX sometimes prints a wrong file name in image error messages: The current directory contains: pic.jpg (JPG image), pic.jpg.tex (e.g. consisting of "\relax") and test.tex: \pdfximage{pic.jpg} \pdfrefximage\pdflastximage \bye Then kpse_find_file will find "pic.jpg.tex" (the automatically adding of ".tex" is sometimes very annoying) and prints the error message: Error: pdftex (file ./pic.jpg): reading image file failed Or if the file pic.jpg.tex is longer: Error: pdftex (file ./pic.jpg): unknown type of image In both cases the file name in the error message is wrong. The error message is thrown by pdftex_fail that looks for cur_file_name and prints it (utils.c). However the real image file name can be changed by kpse_find_file (e.g. adding ".tex"): img_name(img) = kpse_find_file(cur_file_name, kpse_tex_format, true); if (img_name(img) == NULL) pdftex_fail("cannot find image file"); // Here the file name is still correct // (img_name(img) is NULL) // But after this, img_name(img) is not NULL and // contains the used file name, cur_file_name is no // longer valid. checktypebyheader(img); checktypebyextension(img); ... default: pdftex_fail("unknown type of image"); } ... cur_file_name = NULL; ... // checktypebyheader calls pdftex_fail, // and pdftex_fail is also used // later, in each case using the wrong cur_file_name. Fix is easy: cur_file_name = img_name(img); after the NULL check part before checktypebyheader. There are no memory problems. Before cur_file_name points to a static buffer, the return value of makecstring. Thus free must not be used on cur_file_name. And the memory part of img_name(img) is not changed. Yours sincerely Heiko <oberdiek(a)uni-freiburg.de> ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=435&group_id=106

1 0

[ pdftex-Patches-434 ] Remove queued map item handling
by noreply＠sarovar.org 12 Oct '05

12 Oct '05

Patches item #434, was opened at 2005-10-13 01:08 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=434&group_id=106 Category: Fonts Group: None Status: Open Resolution: None Priority: 5 Submitted By: Hartmut Henkel (hhenkel) Assigned to: Nobody (None) Summary: Remove queued map item handling Initial Comment: Remove queued map item handling from mapfile.c ============================================== Formerly all items from \pdfmapfile{+-=mapfile} or \pdfmapline{+-=mapline} were queued up in a list until the next font was selected; then the whole list was processed, e. g. all queued mapfiles or maplines read in. When one gave \pdfmapfile{mapfile} or \pdfmapline{mapline} without +-=, the pending list was cleared. The only practical use for this was to prevent reading in the default mapfile. But this can be done simpler, without queuing. With this patch all \pdfmapfile{+-=mapfile} or \pdfmapline{+-=mapline} requests are processed completely and immediately without queuing, which means that if e. g. a \pdfmapfile{+-=mapfile} primitive is scanned, the mapfile will be read in right away. This happens independently from selecting a font. When \pdfmapfile{+-=mapfile} or \pdfmapline{+-=mapline} is scanned, and there is a default mapfile, it is read first and then the mapfile. Reading of the default mapfile can be disabled by \pdfmapfile{} or \pdfmapline{} or \pdfmapfile{mapfile} or \pdfmapline{mapline} without +-= as long as the default mapfile hasn't already been read in. Latest when the first font is requested, the default mapfile will be read, if this hasn't already been disabled by the mentioned primitives. Apart from possibly reading the default mapfile, there is no other action when a font is requested, since the \pdfmapfile{+-=mapfile} or \pdfmapline{+-=mapline} primitives have already acted right away when they were called. The effects of this patch are the following: * Initial mapfile reading still can be blocked in the usual way. * The difficult to describe queuing mechanism has gone, code gets simpler. * Mapfile reading happens directly by the primitives. * Therefore it's possible to use \pdfretval with the primitives, to check success of the mapfile/line reading (not yet implemented). * As the return value is connected to the \pdfmapfile or \pdfmapline call, one can easier implement other map setting primitives and give them return values. This was not possible before, as the queuing was inbetween. * For any standard use, the patch should be compatible to the former queuing method. The mapfile.c is a patched version of the mapfile.c from Thanh's subfont patch pdftex-20050924.patch.gz for pdftex-1.30.3. Hope it doesn't sound too messy :-) For discussion. Regards, Hartmut ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=434&group_id=106

1 0

Re: [tex-live] Whitespace in file name with all but plain TeX fails
by Martin Schröder 12 Oct '05

12 Oct '05

On 2005-10-11 07:01:53 +0900, Akira Kakuto wrote: > > Indeed, I confirm that > > pdfetex 'v er.tex' > > works in TL 2004 and fails with the current TL pdfetex (both > > i386-linux). The error message is: > > > > ! I can't find file `"v er.tex"'. > > On Windows, pdfetex "v er.tex" is OK. > Please check > char *makecfilename(strnumber s) in utils.c, > where I find #ifdef WIN32. Is this by chance bug #377 again? :-( Best Martin PS: Followup -> ntg-pdftex -- http://www.tm.oneiros.de

4 6

pdftex documentation
by Reinhard Kotucha 10 Oct '05

10 Oct '05

Hi, is there newer documentation for pdftex available than that in the TeXLive repository? The manual in the TL repository seems to be out-of-date and I'm sure that Pawel already has something better. For this documentation (or documentation in general), a smaller value of \pdfminorversion would make more sense. Not everyone has the latest version of Acroread and some people avoid AR7 because it is so slow. Regards, Reinhard -- ---------------------------------------------------------------------------- Reinhard Kotucha Phone: +49-511-4592165 Marschnerstr. 25 D-30167 Hannover mailto:reinhard.kotucha@web.de ---------------------------------------------------------------------------- Microsoft isn't the answer. Microsoft is the question, and the answer is NO. ----------------------------------------------------------------------------

4 8

Re: [tex-live] pdftex documentation
by karl＠freefriends.org 09 Oct '05

09 Oct '05

we have on p4 some (perhaps) obsolete files: pdftex-t.txt, As I wrote. Also pdftex-i.tex pdftex-w.pdf pdftex-w.tex moreover texmf/doc/pdftex/examples/ can be also removed, as pdftex has something better (I believe) in manual/samplepdf/ Indeed, I wasn't sure if samplepdf/ was really supposed to replace examples/. Overall, texmf/doc/pdftex in TL is a frustrating mix of files from a variety of places. Advice (or, ideally, a canonical location we can just copy from) would be appreciated. http://tug.org/texlive/devsrc/Master/texmf/doc/pdftex/ Thanks, Karl

2 2

[ pdftex-Patches-432 ] Rules in a PDF qQ group
by noreply＠sarovar.org 09 Oct '05

09 Oct '05

Patches item #432, was opened at 2005-10-06 21:01 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=432&group_id=106 Category: Positioning Group: None Status: Open Resolution: None Priority: 5 Submitted By: Hartmut Henkel (hhenkel) Assigned to: Nobody (None) Summary: Rules in a PDF qQ group Initial Comment: Put rules with their positioning on the page inside a qQ group. Should make \pdfliteral page {...} behave consistently after text or rules or images, as then any positioning starts from the PDF origin; no delta-positioning anymore. It's already being tested in pdfluatex. Just to have it at sarovar... Testing welcome, particularily with text and graphics transforms by graphicx package, to spot backward incompatibilities, if any... Regards, Hartmut ---------------------------------------------------------------------- >Comment By: Hartmut Henkel (hhenkel) Date: 2005-10-09 15:07 Message: Logged In: YES user_id=929 Update pdf_set_origin_temp: Now has (h, v) parameters. Regards, Hartmut ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=432&group_id=106

1 0

[ pdftex-Patches-427 ] Character positioning patch
by noreply＠sarovar.org 09 Oct '05

09 Oct '05

Patches item #427, was opened at 2005-09-11 12:39 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=427&group_id=106 >Category: Positioning Group: None Status: Open Resolution: None Priority: 5 Submitted By: Hartmut Henkel (hhenkel) Assigned to: Nobody (None) Summary: Character positioning patch Initial Comment: Experimental patch increases resolution of /Widths array by 1 fractional digit, makes corrections of type ")-1(" and ")1(" in the TJ array happen much less often, particularily for CM fonts. Gives e. g. 1 % PDF file size shrink for pdfetex web sources compiled into PDF. Rough patch only, not for production. Testing welcome. Regards, Hartmut ---------------------------------------------------------------------- >Comment By: Hartmut Henkel (hhenkel) Date: 2005-10-09 15:06 Message: Logged In: YES user_id=929 Patch extended: Now pdf_set_origin has (h, v) parameters, simplifies pdf_begin_text procedure. ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2005-10-09 00:25 Message: Logged In: YES user_id=929 Removed pdf_first_space_corr variable, as it seems that it was defunct anyway: There was no pdf_end_string procedure call (only place where something is done with pdf_first_space_corr), where afterwards the pdf_h variable (then modified by pdf_first_space_corr) would actually be used. E. g. pdf_moveto uses pdf_last_h instead, and after pdf_end_text there is anyway a pdf_set_origin call. And pdf_begin_string gets simpler. Testing welcome! Regards, Hartmut ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2005-10-03 01:16 Message: Logged In: YES user_id=929 patch updated: now the TJ array building in procedure pdf_begin_string is simplified/tidied up. Testing welcome! Regards, Hartmut ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=427&group_id=106

1 0

[ pdftex-Patches-427 ] Character positioning patch
by noreply＠sarovar.org 08 Oct '05

08 Oct '05

Patches item #427, was opened at 2005-09-11 12:39 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=427&group_id=106 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Hartmut Henkel (hhenkel) Assigned to: Nobody (None) Summary: Character positioning patch Initial Comment: Experimental patch increases resolution of /Widths array by 1 fractional digit, makes corrections of type ")-1(" and ")1(" in the TJ array happen much less often, particularily for CM fonts. Gives e. g. 1 % PDF file size shrink for pdfetex web sources compiled into PDF. Rough patch only, not for production. Testing welcome. Regards, Hartmut ---------------------------------------------------------------------- >Comment By: Hartmut Henkel (hhenkel) Date: 2005-10-09 00:25 Message: Logged In: YES user_id=929 Removed pdf_first_space_corr variable, as it seems that it was defunct anyway: There was no pdf_end_string procedure call (only place where something is done with pdf_first_space_corr), where afterwards the pdf_h variable (then modified by pdf_first_space_corr) would actually be used. E. g. pdf_moveto uses pdf_last_h instead, and after pdf_end_text there is anyway a pdf_set_origin call. And pdf_begin_string gets simpler. Testing welcome! Regards, Hartmut ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2005-10-03 01:16 Message: Logged In: YES user_id=929 patch updated: now the TJ array building in procedure pdf_begin_string is simplified/tidied up. Testing welcome! Regards, Hartmut ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=427&group_id=106

1 0

[ pdftex-Patches-432 ] Rules in a PDF qQ group
by noreply＠sarovar.org 06 Oct '05

06 Oct '05

Patches item #432, was opened at 2005-10-06 21:01 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=432&group_id=106 Category: Positioning Group: None Status: Open Resolution: None Priority: 5 Submitted By: Hartmut Henkel (hhenkel) Assigned to: Nobody (None) Summary: Rules in a PDF qQ group Initial Comment: Put rules with their positioning on the page inside a qQ group. Should make \pdfliteral page {...} behave consistently after text or rules or images, as then any positioning starts from the PDF origin; no delta-positioning anymore. It's already being tested in pdfluatex. Just to have it at sarovar... Testing welcome, particularily with text and graphics transforms by graphicx package, to spot backward incompatibilities, if any... Regards, Hartmut ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=432&group_id=106

1 0

[ pdftex-Patches-427 ] Character positioning patch
by noreply＠sarovar.org 02 Oct '05

02 Oct '05

Patches item #427, was opened at 2005-09-11 12:39 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=427&group_id=106 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Hartmut Henkel (hhenkel) Assigned to: Nobody (None) Summary: Character positioning patch Initial Comment: Experimental patch increases resolution of /Widths array by 1 fractional digit, makes corrections of type ")-1(" and ")1(" in the TJ array happen much less often, particularily for CM fonts. Gives e. g. 1 % PDF file size shrink for pdfetex web sources compiled into PDF. Rough patch only, not for production. Testing welcome. Regards, Hartmut ---------------------------------------------------------------------- >Comment By: Hartmut Henkel (hhenkel) Date: 2005-10-03 01:16 Message: Logged In: YES user_id=929 patch updated: now the TJ array building in procedure pdf_begin_string is simplified/tidied up. Testing welcome! Regards, Hartmut ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=427&group_id=106

1 0

Re: GrailTeX -- Yet Another TeX Distribution
by Nagy Bence 01 Oct '05

01 Oct '05

Dear TeX-friends, I made a compact LaTeX-based TeX-distribution which can be very usable e.g. for building TeX-based web solutions. GrailTeX is downloadable from http://www.tipogral.hu/index.rhtml/grailtex Most interesting features: package-based architecture with dependency support, the latest pdfeTeX binary (named grailtex) with unstable patches, Latin Modern Type1 fonts instead of bitmapped Metafont Computer Modern (EC) files... There is currently just a minimal documentation on its website. Any comments are welcomed! Greetings, Bence -- Nagy Bence -> Magyar Grafika | www.mgonline.hu -> Tipográl.hu | www.tipogral.hu

2 1

Re: error messages, lack of
by Hans Hagen 21 Sep '05

21 Sep '05

Hi, In the process of tug boat preparations, Karl and I exchanges some mails about font problems (changes in latin modern packaging, resulting in missing encoding files and such) > What kind of error messages? > >I just had in mind the actual errors reported by TeX, starting with "!". >The hard part would be extracting the file/line number information, but >even just leaving that out and reporting > grep \! foo.log >would be an improvement. > > about missing fonts? > > i wonder if we can have a separate log for that: jobname.flg (flg = font log) or so, mentioning: used fonts (tfm, vf, pfb, ...) used map files used enc files all plus exact location, something: [input file] [input line if relevant] [pdf pagenumber] [file|char] [status] [location] the status can be: ok, missing, etc This then could be controlled by: \pdffontlogfile{name} \pdffontloglevel<number> level=0 : no messages/file level=1 : only problems level=2 : all (rough idea, but i think we should consider something like this if only that currently it all depends on luck if you notice the missing glyph messages in the log) 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 -----------------------------------------------------------------

1 0

[ pdftex-Feature Requests-431 ] support for changebar
by noreply＠sarovar.org 20 Sep '05

20 Sep '05

Feature Requests item #431, was opened at 2005-09-12 05:24 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=431&group_id=106 Category: None Group: None Status: Closed Resolution: Out of Date Priority: 5 Submitted By: Rob MacLeod (rsmacleod) Assigned to: Nobody (None) Summary: support for changebar Initial Comment: There appears to be a fix to the problems in pdflatex with the changebar.sty and I wonder if this fix could become part of the standard release. Without this, each time we do a local update (via teTeX and fink) we have to install the patch and do a manual update. We love using pdflatex but not having changebar capability is a real problem for our grant writing activities. Thanks for your support of the system!!! Cheers, Rob (University of Utah) ---------------------------------------------------------------------- >Comment By: Rob MacLeod (rsmacleod) Date: 2005-09-20 07:17 Message: Logged In: YES user_id=2860 Got it, installed it, works like a charm. Many thanks!!! Rob ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2005-09-20 06:03 Message: Logged In: YES user_id=1608 By tomorrow it will probably be all over CTAN: http://www.ctan.org/tex-archive/macros/latex/contrib/changebar/ If you want it right now, use http://ftp.dante.de/tex-archive/macros/latex/contrib/changebar/ ---------------------------------------------------------------------- Comment By: Rob MacLeod (rsmacleod) Date: 2005-09-20 05:55 Message: Logged In: YES user_id=2860 Where do I find version 3.5? The archives all stop at 3.4. ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2005-09-20 01:47 Message: Logged In: YES user_id=1608 This is fixed on the other end: The latest version of changebar.sty (3.5) now supports pdflatex, thanks to a set of fixes by Piet van Oostrum. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=431&group_id=106

1 0

[ pdftex-Feature Requests-431 ] support for changebar
by noreply＠sarovar.org 20 Sep '05

20 Sep '05

Feature Requests item #431, was opened at 2005-09-12 14:24 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=431&group_id=106 Category: None Group: None Status: Closed Resolution: Out of Date Priority: 5 Submitted By: Rob MacLeod (rsmacleod) Assigned to: Nobody (None) Summary: support for changebar Initial Comment: There appears to be a fix to the problems in pdflatex with the changebar.sty and I wonder if this fix could become part of the standard release. Without this, each time we do a local update (via teTeX and fink) we have to install the patch and do a manual update. We love using pdflatex but not having changebar capability is a real problem for our grant writing activities. Thanks for your support of the system!!! Cheers, Rob (University of Utah) ---------------------------------------------------------------------- >Comment By: Taco Hoekwater (taco) Date: 2005-09-20 15:03 Message: Logged In: YES user_id=1608 By tomorrow it will probably be all over CTAN: http://www.ctan.org/tex-archive/macros/latex/contrib/changebar/ If you want it right now, use http://ftp.dante.de/tex-archive/macros/latex/contrib/changebar/ ---------------------------------------------------------------------- Comment By: Rob MacLeod (rsmacleod) Date: 2005-09-20 14:55 Message: Logged In: YES user_id=2860 Where do I find version 3.5? The archives all stop at 3.4. ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2005-09-20 10:47 Message: Logged In: YES user_id=1608 This is fixed on the other end: The latest version of changebar.sty (3.5) now supports pdflatex, thanks to a set of fixes by Piet van Oostrum. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=431&group_id=106

1 0

[ pdftex-Feature Requests-431 ] support for changebar
by noreply＠sarovar.org 20 Sep '05

20 Sep '05

Feature Requests item #431, was opened at 2005-09-12 05:24 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=431&group_id=106 Category: None Group: None Status: Closed Resolution: Out of Date Priority: 5 Submitted By: Rob MacLeod (rsmacleod) Assigned to: Nobody (None) Summary: support for changebar Initial Comment: There appears to be a fix to the problems in pdflatex with the changebar.sty and I wonder if this fix could become part of the standard release. Without this, each time we do a local update (via teTeX and fink) we have to install the patch and do a manual update. We love using pdflatex but not having changebar capability is a real problem for our grant writing activities. Thanks for your support of the system!!! Cheers, Rob (University of Utah) ---------------------------------------------------------------------- >Comment By: Rob MacLeod (rsmacleod) Date: 2005-09-20 05:55 Message: Logged In: YES user_id=2860 Where do I find version 3.5? The archives all stop at 3.4. ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2005-09-20 01:47 Message: Logged In: YES user_id=1608 This is fixed on the other end: The latest version of changebar.sty (3.5) now supports pdflatex, thanks to a set of fixes by Piet van Oostrum. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=431&group_id=106

1 0

Re: support for changebar
by Thanh Han The 20 Sep '05

20 Sep '05

> ---------------------------------------------------------------------- > > >Comment By: Taco Hoekwater (taco) > Date: 2005-09-20 10:47 > > Message: > Logged In: YES > user_id=1608 > > > This is fixed on the other end: > > The latest version of changebar.sty (3.5) now supports > pdflatex, thanks to a set of fixes by Piet van Oostrum. a wonderful news! Thanh

1 0

[ pdftex-Feature Requests-431 ] support for changebar
by noreply＠sarovar.org 20 Sep '05

20 Sep '05

Feature Requests item #431, was opened at 2005-09-12 14:24 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=431&group_id=106 Category: None Group: None >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Rob MacLeod (rsmacleod) Assigned to: Nobody (None) Summary: support for changebar Initial Comment: There appears to be a fix to the problems in pdflatex with the changebar.sty and I wonder if this fix could become part of the standard release. Without this, each time we do a local update (via teTeX and fink) we have to install the patch and do a manual update. We love using pdflatex but not having changebar capability is a real problem for our grant writing activities. Thanks for your support of the system!!! Cheers, Rob (University of Utah) ---------------------------------------------------------------------- >Comment By: Taco Hoekwater (taco) Date: 2005-09-20 10:47 Message: Logged In: YES user_id=1608 This is fixed on the other end: The latest version of changebar.sty (3.5) now supports pdflatex, thanks to a set of fixes by Piet van Oostrum. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=431&group_id=106

1 0

Re: [NTG-pdftex] pdfpagebox
by Thanh Han The 19 Sep '05

19 Sep '05

good. I am on way to do that. Another issue is that I am implementing a primitive requrested by Cho, to grab the BBox of an included pdf. Syntax: \pdfximagebbox\pdflastximage 1 => print BBox1 ... \pdfximagebbox\pdflastximage 4 => print BBox4 A question here: what should be printed? something like 10pt, or 10sp, or 10bp, or just 10? 10pt seems to be easy and also consistent with syntax of similar primitives, however the BBox of pdf is often in bp, so instead of 10bp we would get 10.03749pt. Is this a problem? Thanh On Thu, Sep 15, 2005 at 11:52:03AM +0200, Pawel Jackowski wrote: > Hi, > > >>at the moment \pdfforcepagebox overrides the setting given > >>by \pdfximage. Isn't this a little bit unlogical that the global > >>setting overrides the setting in individual use of > >>\pdfximage? > > indeed. > > >>I suggest to change \pdfforcepagebox to \pdfpagebox as a > >>global variable indicating which pagebox shoud be used in case > >>no pagebox specification is given with a \pdfximage. > >>used. > >> > >> > >makes sense > > good idea. > -- > Pawe/l Jackowski > P.Jackowski(a)gust.org.pl

4 7

pdfpagebox
by Thanh Han The 19 Sep '05

19 Sep '05

Hi, at the moment \pdfforcepagebox overrides the setting given by \pdfximage. Isn't this a little bit unlogical that the global setting overrides the setting in individual use of \pdfximage? I suggest to change \pdfforcepagebox to \pdfpagebox as a global variable indicating which pagebox shoud be used in case no pagebox specification is given with a \pdfximage. used. Thanh

4 3

useless error message
by Reinhard Kotucha 18 Sep '05

18 Sep '05

Hi, I have a few problems with tex4ht. I don't know much about it so I depend on the error messages I get. I'm using This is pdfeTeXk, Version 3.141592-1.30.3-2.2 (Web2C 7.5.5) That's what I got: __________________________________________________________________ (/ext/TL-src/Master/texmf-vntex/tex/latex/vntex/t5cmr.fd) ! pdfTeX error (\pdfobj): used while \pdfoutput is not set. reserved@a ->immediate pdfobj stream file {reserved@f }expandafter xdef csna... l.100 \fontencoding\encodingdefault\selectfont __________________________________________________________________ What does "\pdfoutput is not set" want to tell me? Is it undefined? Though tex4ht is based on latex, (which is in fact pdfelatex) any .tex file can contain something like \let\pdfoutput\undefined. Or does it mean that it is set to 0? Anyway, the message is useless and should either be ! pdfTeX error (\pdfobj): used while \pdfoutput is undefined. or ! pdfTeX error (\pdfobj): used while \pdfoutput=<value>. Regards, Reinhard -- ---------------------------------------------------------------------------- Reinhard Kotucha Phone: +49-511-4592165 Marschnerstr. 25 D-30167 Hannover mailto:reinhard.kotucha@web.de ---------------------------------------------------------------------------- Microsoft isn't the answer. Microsoft is the question, and the answer is NO. ----------------------------------------------------------------------------

3 3

Re: [NTG-pdftex] useless error message
by Thanh Han The 18 Sep '05

18 Sep '05

On Sun, Sep 18, 2005 at 10:38:57AM +0200, Hartmut Henkel wrote: > On Sun, 18 Sep 2005, Reinhard Kotucha wrote: > > > Anyway, the message is useless and should either be > > > > ! pdfTeX error (\pdfobj): used while \pdfoutput is undefined. > > > > or > > > > ! pdfTeX error (\pdfobj): used while \pdfoutput=<value>. > > or maybe: > > ! pdfTeX error (\pdfobj): not allowed in DVI mode (\pdfoutput<=0). this sounds good. I will change it as Hartmut suggested. Thanh

1 0

Re: [NTG-pdftex] pdfpagebox
by Thanh Han The 16 Sep '05

16 Sep '05

On Fri, Sep 16, 2005 at 02:03:12AM +0200, Heiko Oberdiek wrote: > > [...] > > Thus normalization is a good idea. good, let's do so. Thanh

1 0