pdftex snapshot

newer
[ pdftex-Feature Requests-354 ]...

The Thanh Han

24 May 2005 24 May '05

10:22 a.m.

Show replies by date

Taco Hoekwater

24 May 24 May

11:40 a.m.

Hi Thanh / TeX-k people, There are some compile-time warnings in the latest snapshots of pdftex, that are very simple to fix. In pdftex.ch: the macro pdf_room() first checks its argument against the pdf_buf_size, but pdf_buf_size is larger (16384) than the largest possible value for the type of k (a C char), so there are always two compile-time warnings from gcc: pdfetex0.c: In function `zpdfprintint': pdfetex0.c:2696: warning: comparison is always false due to limited range of data type pdfetex1.c: In function `zpdfprintfwint': pdfetex1.c:8673: warning: comparison is always false due to limited range of data type Here is a small (two lines) change that surpresses these compile-time warnings in pdftex0.c and pdftex1.c: -------------------------------------------------------- diff pdftex.ch.orig pdftex.ch 1215c1215 < var k:0..23; {index to current digit; we assume that $|n|<10^{23}$} ---

...

var k:integer; {index to current digit; we assume that $|n|<10^{23}$} 2015c2015 < var k:0..23;

...

var k:integer;

In pdftex.ch, there is a similar message in tex.ch:load_fmt_file(): items in hyf_next[1] cannot be larger than max_trie_op (65535): pdfetexini.c: In function `loadfmtfile': pdfetexini.c:4194: warning: comparison is always false due to limited range of data type Here is a different one-line patch to fix that as well: -------------------------------------------------------------- diff tex.ch.orig tex.ch 227c227 < @!max_trie_op=ssup_trie_opcode; {largest possible trie opcode for any language} ---

...

@!max_trie_op=ssup_trie_opcode-1; {largest possible trie opcode for any language}

Greetings, Taco

Hartmut Henkel

10:18 p.m.

New subject: 20050525 pdfretval last minute changes

Hi Thanh, the attached last-minute-patch to pdftex.ch contains: 1. Akira's identification of binary PDF file, now by special string "PTEX" with 128 added to each ASCII char (highest bit set). 2. Taco's fix for compile time warnings (without the tex-k one). 3. And i would like to propose to change the register \pdfstrcompresult into simple \pdfretval. Reason is that it would be nice to have a global integer "return value" register for general use with utility functions, e. g. to check whether image embedding failed or so, and i also need such a return value register for map related stuff... When i saw that \pdfstrcompresult is already a typical integer return value for \pdfstrcomp, i thought that this would be the ideal moment to start a \pdfretval. After the patch, comparison by \pdfstrcomp would set \pdfretval to -1, 0, or 1. You sure will have ideas for what to set \pdfretval. It then normally should contain a 0 for "success", some positive value coding various "fail" conditions, or other e. g. signed values as after \pdfstrcomp... Question is, who already is using \pdfstrcomp, and whether he can live with such a new \pdfretval instead? Regards, Hartmut --- pdftex.ch.orig 2005-05-24 09:43:10.000000000 +0200 +++ pdftex.ch 2005-05-24 21:33:31.443521131 +0200 @@ -382,7 +382,7 @@ @d pdf_last_annot_code = pdftex_first_rint_code + 5 {code for \.{\\pdflastannot}} @d pdf_last_x_pos_code = pdftex_first_rint_code + 6 {code for \.{\\pdflastxpos}} @d pdf_last_y_pos_code = pdftex_first_rint_code + 7 {code for \.{\\pdflastypos}} -@d pdf_strcmp_result_code = pdftex_first_rint_code + 8 {result of \.{\\pdfstrcmp}} +@d pdf_retval_code = pdftex_first_rint_code + 8 {global multi-purpose return value} @d pdf_last_ximage_colordepth_code = pdftex_first_rint_code + 9 {code for \.{\\pdflastximagecolordepth}} @d elapsed_time_code = pdftex_first_rint_code + 10 {code for \.{\\elapsedtime}} @d pdftex_last_item_codes = pdftex_first_rint_code + 10 {end of \pdfTeX's command codes} @@ -410,8 +410,8 @@ @!@:pdf_last_x_pos_}{\.{\\pdflastxpos} primitive@> primitive("pdflastypos",last_item,pdf_last_y_pos_code);@/ @!@:pdf_last_y_pos_}{\.{\\pdflastypos} primitive@> -primitive("pdfstrcmpresult",last_item,pdf_strcmp_result_code);@/ -@!@:pdf_strcmp_result_}{\.{\\pdfstrcmpresult} primitive@> +primitive("pdfretval",last_item,pdf_retval_code);@/ +@!@:pdf_retval_}{\.{\\pdfretval} primitive@> primitive("pdflastximagecolordepth",last_item,pdf_last_ximage_colordepth_code);@/ @!@:pdf_last_ximage_colordepth_}{\.{\\pdflastximagecolordepth} primitive@> primitive("elapsedtime",last_item,elapsed_time_code); @@ -429,7 +429,7 @@ pdf_last_annot_code: print_esc("pdflastannot"); pdf_last_x_pos_code: print_esc("pdflastxpos"); pdf_last_y_pos_code: print_esc("pdflastypos"); - pdf_strcmp_result_code: print_esc("pdfstrcmpresult"); + pdf_retval_code: print_esc("pdfretval"); pdf_last_ximage_colordepth_code: print_esc("pdflastximagecolordepth"); elapsed_time_code: print_esc("elapsedtime"); othercases print_esc("badness") @@ -456,7 +456,7 @@ pdf_last_annot_code: cur_val := pdf_last_annot; pdf_last_x_pos_code: cur_val := pdf_last_x_pos; pdf_last_y_pos_code: cur_val := pdf_last_y_pos; - pdf_strcmp_result_code: cur_val := pdf_strcmp_result; + pdf_retval_code: cur_val := pdf_retval; pdf_last_ximage_colordepth_code: cur_val := pdf_last_ximage_colordepth; elapsed_time_code: cur_val := get_microinterval; end; {there are no other cases} @@ -488,7 +488,7 @@ in {\sl Technische Grundlagen zur Satzherstellung\/} (Bern, 1980). The Didot point has been newly standardized in 1978; it's now exactly $\rm 1\,nd=0.375\,mm$. -Conversion uses the equation $0.375=21681/20320/72.27*25.4$. +Conversion uses the equation $0.375=21681/20320/72.27\cdot25.4$. The new Cicero follows the new Didot point; $\rm 1\,nc=12\,nd$. @z @@ -929,7 +929,13 @@ pdf_buf[6] := "."; pdf_buf[7] := "4"; pdf_buf[8] := pdf_new_line_char; -pdf_ptr := 9; +pdf_buf[9] := "%"; +pdf_buf[10] := 208; {``PTEX''} +pdf_buf[11] := 212; +pdf_buf[12] := 197; +pdf_buf[13] := 216; +pdf_buf[14] := pdf_new_line_char; +pdf_ptr := 15; pdf_gone := 0; zip_write_state := no_zip; pdf_minor_version_written := false; @@ -1212,7 +1218,7 @@ end; procedure pdf_print_int(n:integer); {print out a integer to PDF buffer} -var k:0..23; {index to current digit; we assume that $|n|<10^{23}$} +var k:integer; {index to current digit ($0\le k\le23$); we assume that $|n|<10^{23}$} m:integer; {used to negate |n| in possibly dangerous cases} begin k:=0; @@ -2012,7 +2018,7 @@ @p procedure pdf_print_fw_int(n, w: integer); {print out an integer with fixed width; used for outputting cross-reference table} -var k:0..23; +var k:integer; {$0\le k\le23$} begin k:=0; repeat dig[k]:=n mod 10; n:=n div 10; incr(k); @@ -4766,7 +4772,7 @@ else result := -1; done: - pdf_strcmp_result := result; + pdf_retval := result; flush_str(s2); flush_str(s1); end; @@ -5642,7 +5648,7 @@ end @ @= -@!pdf_strcmp_result: integer; {the last result of \.{\\pdfstrcmp}} +@!pdf_retval: integer; {global multi-purpose return value} @ @= compare_strings

The Thanh Han

25 May 25 May

4:30 a.m.

New subject: 20050525 pdfretval last minute changes

Hi Hartmut, thanks for the patch. Nobody is using \pdfstrcomp, so we can safely replace it. I will upload another snapshot soon. Regards, Thanh On Tue, May 24, 2005 at 10:18:09PM +0200, Hartmut Henkel wrote:

...

Hi Thanh,

the attached last-minute-patch to pdftex.ch contains:

1. Akira's identification of binary PDF file, now by special string "PTEX" with 128 added to each ASCII char (highest bit set).

2. Taco's fix for compile time warnings (without the tex-k one).

3. And i would like to propose to change the register \pdfstrcompresult into simple \pdfretval. Reason is that it would be nice to have a global integer "return value" register for general use with utility functions, e. g. to check whether image embedding failed or so, and i also need such a return value register for map related stuff...

When i saw that \pdfstrcompresult is already a typical integer return value for \pdfstrcomp, i thought that this would be the ideal moment to start a \pdfretval. After the patch, comparison by \pdfstrcomp would set \pdfretval to -1, 0, or 1.

You sure will have ideas for what to set \pdfretval. It then normally should contain a 0 for "success", some positive value coding various "fail" conditions, or other e. g. signed values as after \pdfstrcomp...

Question is, who already is using \pdfstrcomp, and whether he can live with such a new \pdfretval instead?

Regards, Hartmut

Hans Hagen

8:09 a.m.

New subject: 20050525 pdfretval last minute changes

The Thanh Han wrote:

...

...
Question is, who already is using \pdfstrcomp, and whether he can live with such a new \pdfretval instead?

i can live with the change, i'll use the command once the new pdftex is around 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 -----------------------------------------------------------------

Taco Hoekwater

24 May 24 May

11:50 a.m.

The Thanh Han wrote:

...

| - moved all extensions in pdfxtex to pdftex

new pdftex = former pdfxtex, and new pdfetex = former pdfxtex + etex, right? Taco

The Thanh Han

25 May 25 May

4:26 a.m.

yes exactly. Thanh On Tue, May 24, 2005 at 11:50:43AM +0200, Taco Hoekwater wrote:

...

The Thanh Han wrote:

...
| - moved all extensions in pdfxtex to pdftex

new pdftex = former pdfxtex, and new pdfetex = former pdfxtex + etex, right?

Taco _______________________________________________ ntg-pdftex mailing list ntg-pdftex@ntg.nl http://www.ntg.nl/mailman/listinfo/ntg-pdftex

Vit Zyka

24 May 24 May

1:18 p.m.

The Thanh Han wrote:

...

| - moved all extensions in pdfxtex to pdftex

Is somewhere a desription of the pdfxtex extensions? Thanks Vit Zyka

The Thanh Han

25 May 25 May

4:29 a.m.

On Tue, May 24, 2005 at 01:18:08PM +0200, Vit Zyka wrote:

...

The Thanh Han wrote:

...
| - moved all extensions in pdfxtex to pdftex

Is somewhere a desription of the pdfxtex extensions?

here is a very brief and incomplete ovewview: ,-------- | \item There is a program called \<PDFXTEX>, which is a variant of | \<PDFETEX> that contains experimental features. Those features may be | moved to \<PDFTEX> when they seem to be useful and stable. At the moment | the following extensions are avaiable: | \begin{itemize} | \item |\pdflastximagecolordepth| returns the last color depth of a | bitmapped image; | \item |\pdfximage| supports a keyword |colorspace| following an object | number representing a \<PDF> ColorSpace object; | \item |\pdfstrcmp| compares two strings; | \item |\pdfescapestring| and |\pdflastescapedstring| provide a means to | escape strings; | \item |\pdffirstlineheight|, |\pdflastlinedepth|, |\pdfeachlineheight| | and |\pdfeachlinedepth| allow fixing line dimensions during paragraph | buiding; | \item various extensions from Taco Hoekwater: | \begin{itemize} | \item support for dimension unit |px|; | \item |\tagcode| primitive allowing read and write access to a | character's |char_tag| info. | \item |\quitvmode| primitive quits vertical mode; | \end{itemize} | \end{itemize} | \end{enumerate} `-------- pls a few more that have been added recently. Those will be described in the pdftex manual soon. Thanh

Fabrice Popineau

26 May 26 May

10:56 a.m.

Hi, I don't know if it is me failing to properly upgrade my source tree but I get a strange behaviour since 1.21b. This LaTeX document: \documentclass{article} \usepackage{utopia} \begin{document} This is a test! {\it This is a test!} {\bf This is a test!} \end{document} ends up in a PDF file where the utopia font is said to be impossible to extract to display by Acrobat 7.0. Can anybody prove me wrong? -- Fabrice

Fabrice Popineau

11:22 a.m.

Doesn't work either with lmodern or fourier instead of utopia. Looking at the attached file, it seems that pdftex fails to include the last font. -- Fabrice

Hans Hagen

5:35 p.m.

Fabrice Popineau wrote:

...

Doesn't work either with lmodern or fourier instead of utopia. Looking at the attached file, it seems that pdftex fails to include the last font.

acrobat also has problems with two of the embeded lm ones 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 -----------------------------------------------------------------

Vit Zyka

8:22 p.m.

New subject: inclusion of PDF with hz-alg expandeded font

Hallo, is the next bug known? When one includes a PDF (as a figure) with expanded fonts by hz-alg then this text is invisible (but neither AR7.0.1win and pdfetex complains). Example: % --- PDF with hz \pdfpagewidth=12cm \pdfpageheight=12cm \hsize=8cm The next text is typeset with hz-alg: \vskip1cm \pdfadjustspacing=2 \pdffontexpand\font 25 25 5 autoexpand% \input knuth \end % --- loading PDF with a hz-expanded font loaded as figure: \pdfximage{hz.pdf} \pdfrefximage\pdflastximage \end Version: This is pdfeTeXk, Version 3.141592-1.21b-2.2 (Web2C 7.5.4) Vit Zyka

Hans Hagen

9:26 p.m.

New subject: inclusion of PDF with hz-alg expandeded font

Vit Zyka wrote:

...

Hallo,

is the next bug known? When one includes a PDF (as a figure) with expanded fonts by hz-alg then this text is invisible (but neither AR7.0.1win and pdfetex complains).

Example: % --- PDF with hz \pdfpagewidth=12cm \pdfpageheight=12cm \hsize=8cm The next text is typeset with hz-alg: \vskip1cm \pdfadjustspacing=2 \pdffontexpand\font 25 25 5 autoexpand% \input knuth \end % --- loading PDF with a hz-expanded font loaded as figure: \pdfximage{hz.pdf} \pdfrefximage\pdflastximage \end

Version: This is pdfeTeXk, Version 3.141592-1.21b-2.2 (Web2C 7.5.4)

strange indeed; there are font resources in there but the glyph data seems missing (there are encoding vector); acrobat never complains about missing glyphs, only about missing font resources. 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 -----------------------------------------------------------------

The Thanh Han

27 May 27 May

10:28 a.m.

New subject: inclusion of PDF with hz-alg expandeded font

I use the following macro to produce one-page ,-------- | \newbox\epdfbox | | % mkepdf{hmargin}{vmargin}{text} | \long\def\mkepdf#1#2#3{% | \pdfhorigin=1sp | \advance \pdfhorigin #1 | \pdfvorigin=1sp | \advance \pdfvorigin #2 | \setbox\epdfbox=\vbox{#3} | \pdfpagewidth=\wd\epdfbox | \advance \pdfpagewidth 2\pdfhorigin | \pdfpageheight=\ht\epdfbox | \advance \pdfpageheight \dp\epdfbox | \advance \pdfpageheight 2\pdfvorigin | \shipout\box\epdfbox | } `-------- Usage: \mkepdf{1bp}{1bp}{\hbox{Hello, world!}} or \mkepdf{1bp}{1bp}{% \hsize=3in \input foo.tex \par } HTH, Thanh

Hartmut Henkel

26 May 26 May

9:28 p.m.

New subject: inclusion of PDF with hz-alg expandeded font

On Thu, 26 May 2005, Vit Zyka wrote:

...

is the next bug known? When one includes a PDF (as a figure) with expanded fonts by hz-alg then this text is invisible (but neither AR7.0.1win and pdfetex complains).

Seems the text is just off the page. Try % --- PDF with hz \pdfpagewidth=12cm \pdfpageheight=12cm \hsize=8cm \vsize=8cm The next text is typeset with hz-alg: \vskip1cm \pdfadjustspacing=2 \pdffontexpand\font 25 25 5 autoexpand% \input tufte %\end % --- loading PDF with a hz-expanded font loaded as figure: \pdfximage{hz.pdf} \hbox{\pdfrefximage\pdflastximage} \end with \vsize setting. Or extend \pdfpageheight... Regards, Hartmut

Hartmut Henkel

27 May 27 May

3:26 p.m.

New subject: pdftex-20050526: spurious blanks after keywords

Hi Thanh, see this line from Vit:

...

\pdffontexpand\font 25 25 5 autoexpand%

The "%" is needed when in horizontal mode to get rid of a spurious blank. I think we should add a @ there, so that the space after the keyword is ignored (like with e. g. "12pt"). Maybe similar with "\pdfobj reserveobjnum", and with "newwindow" and "nonewwindow". Are there more cases like this? Regards, Hartmut

Hartmut Henkel

5:24 p.m.

New subject: pdftex-20050526: spurious blanks after keywords

Here is a test file that shows spurious blanks after keywords: ---\pdffontexpand\font 25 25 5 autoexpand--- ---\pdfobj reserveobjnum --- ---\pdfdest num1 fitbh --- ---\pdfstartlink goto file{file.pdf} page 1{/FitB}newwindow A\pdfendlink --- \end And below are simple patches for pdftex.ch and hz.ch to avoid these blanks. I hope these are all occurences, and the patch won't cause backward-incompatibilities. Who would want those spaces anyway? Regards, Hartmut --- pdftex.ch.orig 2005-05-26 11:39:32.000000000 +0200 +++ pdftex.ch 2005-05-27 17:02:02.737692220 +0200 @@ -4803,6 +4803,7 @@ begin check_pdfoutput("\pdfobj"); if scan_keyword("reserveobjnum") then begin + @; incr(pdf_obj_count); pdf_create_obj(obj_type_obj, pdf_obj_count); pdf_last_obj := obj_ptr; @@ -5263,10 +5264,12 @@ end else pdf_error("ext1", "identifier type missing"); - if scan_keyword("newwindow") then - pdf_action_new_window(p) := 1 - else if scan_keyword("nonewwindow") then - pdf_action_new_window(p) := 2 + if scan_keyword("newwindow") then begin + pdf_action_new_window(p) := 1; + @; end + else if scan_keyword("nonewwindow") then begin + pdf_action_new_window(p) := 2; + @; end else pdf_action_new_window(p) := 0; if (pdf_action_new_window(p) > 0) and @@ -5310,8 +5313,9 @@ @ @= begin check_pdfoutput("\pdfannot"); - if scan_keyword("reserveobjnum") then - pdf_last_annot := pdf_new_objnum + if scan_keyword("reserveobjnum") then begin + pdf_last_annot := pdf_new_objnum; + @; end else begin if scan_keyword("useobjnum") then begin scan_int; @@ -5507,6 +5511,7 @@ pdf_dest_type(tail) := pdf_dest_fit else pdf_error("ext1", "destination type missing"); + @; if pdf_dest_type(tail) = pdf_dest_fitr then begin scan_alt_rule; {scans |<rule spec>| to |alt_rule|} pdf_width(tail) := width(alt_rule); --- hz.ch.orig 2005-05-21 03:31:58.000000000 +0200 +++ hz.ch 2005-05-27 16:40:18.316931899 +0200 @@ -575,8 +575,9 @@ if (font_stretch = 0) and (font_shrink = 0) then pdf_error("font expansion", "invalid limit"); auto_expand := false; - if scan_keyword("autoexpand") then + if scan_keyword("autoexpand") then begin auto_expand := true; + @; end; {check if the font can be expanded} if (pdf_font_expand_ratio[f] <> 0) then

Hans Hagen

8:07 p.m.

New subject: pdftex-20050526: spurious blanks after keywords

Hartmut Henkel wrote:

...

Here is a test file that shows spurious blanks after keywords:

---\pdffontexpand\font 25 25 5 autoexpand---

---\pdfobj reserveobjnum ---

---\pdfdest num1 fitbh ---

---\pdfstartlink goto file{file.pdf} page 1{/FitB}newwindow A\pdfendlink ---

\end

And below are simple patches for pdftex.ch and hz.ch to avoid these blanks. I hope these are all occurences, and the patch won't cause backward-incompatibilities. Who would want those spaces anyway?

normally one ends such a command with \relax (as with \hrule ...) but pdftex is the only one using keywords without anything behind it so the patch fits into tex's paradigm 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 -----------------------------------------------------------------

Hartmut Henkel

10:30 p.m.

New subject: pdftex-20050526: spurious blanks after keywords

On Fri, 27 May 2005, Hans Hagen wrote:

...

Hartmut Henkel wrote:

...
Here is a test file that shows spurious blanks after keywords:

---\pdffontexpand\font 25 25 5 autoexpand---

---\pdfobj reserveobjnum ---

---\pdfdest num1 fitbh ---

---\pdfstartlink goto file{file.pdf} page 1{/FitB}newwindow A\pdfendlink ---

\end

...

normally one ends such a command with \relax (as with \hrule ...)

\hrule?

...

but pdftex is the only one using keywords without anything behind it so the patch fits into tex's paradigm

yes --- but meanwhile i fear that it might cause complaints from people actively using these blanks in running text (mainly \pdfdest; the others might be harmless as they are still rather new). Would be interesting to know where it might give problems with LaTeX/hyperref. Maybe it's too late now for changing... Regards, Hartmut

Hans Hagen

10:57 p.m.

New subject: pdftex-20050526: spurious blanks after keywords

Hartmut Henkel wrote:

...

\hrule

\hrule sidth 10cm height 10cm height bla bla \hrule sidth 10cm height 10cm \relax height bla bla

...

Maybe it's too late now for changing...

there has been more drastic changes; also, most users use cpackaged macros for that so it's a one place change (if needed at all); users who depend on space being present in deep down hidden primitive usage are in danger anyway 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 -----------------------------------------------------------------

Heiko Oberdiek

28 May 28 May

12:39 a.m.

New subject: pdftex-20050526: spurious blanks after keywords

On Fri, May 27, 2005 at 10:30:58PM +0200, Hartmut Henkel wrote:

...

On Fri, 27 May 2005, Hans Hagen wrote:

...
Hartmut Henkel wrote:

...
Here is a test file that shows spurious blanks after keywords:

---\pdffontexpand\font 25 25 5 autoexpand---

---\pdfobj reserveobjnum ---

---\pdfdest num1 fitbh ---

---\pdfstartlink goto file{file.pdf} page 1{/FitB}newwindow A\pdfendlink ---

...

...
but pdftex is the only one using keywords without anything behind it so the patch fits into tex's paradigm

yes --- but meanwhile i fear that it might cause complaints from people actively using these blanks in running text (mainly \pdfdest; the others might be harmless as they are still rather new).

Would be interesting to know where it might give problems with LaTeX/hyperref.

I have now added \relax after the use of \pdfdest and after \pdfstartlink to be safe in case of future extensions. "reserveobjnum" and \pdffontexpand is not used in hyperref.

...

Maybe it's too late now for changing...

I do not mind. Better a clear interface than something confusing. Yours sincerely Heiko --

Hartmut Henkel

26 May 26 May

8:05 p.m.

Hi Fabrice, i've looked to writet1.c and added diagnostic print lines. Thought that maybe fb_ptr would not be initialized. But it is initialized. This happens during t1_putchar() = fb_putchar() which uses macro alloc_array, which sets fb_ptr. t1_putchar() is used by t1_putline(), and this is called before Length1 is calculated. I initialized fb_ptr also to some weird value; also this didn't matter. After the first t1_putchar() everything was ok. So i can't yet repeat your problem. No idea... Regards, Hartmut

The Thanh Han

11:51 a.m.

Hi, I have tested your file with the latest snapshot. Seems to be ok on linux, ACR7. Thanh On Thu, May 26, 2005 at 10:56:28AM +0200, Fabrice Popineau wrote:

...

Hi,

I don't know if it is me failing to properly upgrade my source tree but I get a strange behaviour since 1.21b. This LaTeX document:

\documentclass{article} \usepackage{utopia}

\begin{document}

This is a test! {\it This is a test!} {\bf This is a test!}

\end{document}

ends up in a PDF file where the utopia font is said to be impossible to extract to display by Acrobat 7.0.

Can anybody prove me wrong?

-- Fabrice

_______________________________________________ ntg-pdftex mailing list ntg-pdftex@ntg.nl http://www.ntg.nl/mailman/listinfo/ntg-pdftex

Fabrice Popineau

12:16 p.m.

* The Thanh Han writes: > Hi, I have tested your file with the latest snapshot. Seems to be > ok on linux, ACR7. It still fails for me. You removed 2 occurences of save_offset() in pdftexdir/writet1.c : @@ -1050,7 +1035,6 @@ static void t1_include(void) { - save_offset(); do { t1_getline(); t1_scan_param(); @@ -1381,7 +1365,6 @@ static void t1_subset_ascii_part(void) { int i, j; - save_offset(); t1_getline(); while (!t1_prefix("/Encoding")) { t1_scan_param(); @@ -1391,15 +1374,13 @@ If I reinstate them, I get readable pdf files again. The Length1 values for t1 fonts were wrong. Fabrice

Hartmut Henkel

5:04 p.m.

On Thu, 26 May 2005, Fabrice Popineau wrote:

...

* The Thanh Han writes:

> Hi, I have tested your file with the latest snapshot. Seems to be > ok on linux, ACR7.

It still fails for me. You

i did it, it was the patch for bug-315 (the Length1 value was wrong). The change seemed safe to me. The full patch included also a section @@ -1717,6 +1715,7 @@ { read_encoding_only = false; #ifdef pdfTeX + t1_save_offset = 0; if (strcasecmp(strend(fm_fontfile(fm_cur)) - 4, ".otf") == 0) { if (!is_included(fm_cur) || is_subsetted(fm_cur)) pdftex_fail("OTF fonts must be included entirely"); Seems this is in. Will check again...

...

removed 2 occurences of save_offset() in pdftexdir/writet1.c :

@@ -1050,7 +1035,6 @@

static void t1_include(void) { - save_offset(); do { t1_getline(); t1_scan_param(); @@ -1381,7 +1365,6 @@ static void t1_subset_ascii_part(void) { int i, j; - save_offset(); t1_getline(); while (!t1_prefix("/Encoding")) { t1_scan_param(); @@ -1391,15 +1374,13 @@

If I reinstate them, I get readable pdf files again. The Length1 values for t1 fonts were wrong.

Regards, Hartmut

7154

Age (days ago)

7157

Last active (days ago)

List overview

Download

25 comments

7 participants

participants (7)

Fabrice Popineau
Hans Hagen
Hartmut Henkel
Heiko Oberdiek
Taco Hoekwater
The Thanh Han
Vit Zyka

pdftex snapshot

The Thanh Han

The Thanh Han

The Thanh Han

The Thanh Han

The Thanh Han

Heiko Oberdiek

The Thanh Han

tags

participants (7)