[ pdftex-Bugs-294 ] pdfmovechars/encoding problem
Bugs item #294, was opened at 2005-02-15 21:06
You can respond by visiting:
http://sarovar.org/tracker/?func=detail&atid=493&aid=294&group_id=106
Category: Fonts
Group: v1.21a
Status: Open
Resolution: None
Priority: 5
Submitted By: Hartmut Henkel (hhenkel)
Assigned to: The Thanh Han (hanthethanh)
Summary: pdfmovechars/encoding problem
Initial Comment:
This has been reported by Jörg Heinrich at 1 Feb. 2005
on the pdftex list (Subject: [pdftex] pdfetex). The
following derived example leads to a segfault:
% this works:
%\pdfmovechars=1
% this gives segfault:
\pdfmovechars=2
% this works:
%\pdfmapline{phvr8r Helvetica <8r.enc
Hi, this issue needs revision as well. In the beginning there were requests to move chars in range [0, 32) to higher slots if possible, so I introduced \pdfmovechars. I don't use this feature myself, and it seems that almost nobody else does, thus the bug slipped out without being noticed for quite a long time. Now to summarize the issue: when possible, move all chars in range [0, 32) to higher slots. The question is, what ``when possible'' means? When a tfm has only 128 chars as cm font, it's simple: move chars in range [0, 32) to [160, 192). When a tfm has 256 chars with some free slots (assigned to .notdef glygh), move chars in [0, 32) to these slots. But the number of free slots maybe less than 32, then what we should do? Before fixing this bug, I would like to discuss whether it makes sense to support this feature at all. It seems that when an encoding has more than 128 assigned chars, then usually the number of free slots is less than 32. Hence I suggest 2 solutions: 1) completely remove this feature; or 2) only consider fonts with 128 chars. Thanh On Wed, Feb 16, 2005 at 01:36:41AM +0530, noreply@sarovar.org wrote:
Bugs item #294, was opened at 2005-02-15 21:06 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=294&group_id=106
Category: Fonts Group: v1.21a Status: Open Resolution: None Priority: 5 Submitted By: Hartmut Henkel (hhenkel) Assigned to: The Thanh Han (hanthethanh) Summary: pdfmovechars/encoding problem
Initial Comment: This has been reported by Jörg Heinrich at 1 Feb. 2005 on the pdftex list (Subject: [pdftex] pdfetex). The following derived example leads to a segfault:
% this works: %\pdfmovechars=1 % this gives segfault: \pdfmovechars=2 % this works: %\pdfmapline{phvr8r Helvetica <8r.enc
----------------------------------------------------------------------
You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=294&group_id=106 _______________________________________________ ntg-pdftex mailing list ntg-pdftex@ntg.nl http://www.ntg.nl/mailman/listinfo/ntg-pdftex
On Thu, 17 Feb 2005, The Thanh Han wrote:
this issue needs revision as well. In the beginning there were requests to move chars in range [0, 32) to higher slots if possible, so I introduced \pdfmovechars. I don't use this feature myself, and it seems that almost nobody else does, thus the bug slipped out without being noticed for quite a long time.
more see in Thanh's original post. Nobody followed up. What to do? I never used this, either, nor understand for what it would do good. Should we remove \pdfmovechars to close this bug? Regards, Hartmut
"Hartmut" == Hartmut Henkel
writes:
On Thu, 17 Feb 2005, The Thanh Han wrote:
this issue needs revision as well. In the beginning there were requests to move chars in range [0, 32) to higher slots if possible, so I introduced \pdfmovechars. I don't use this feature myself, and it seems that almost nobody else does, thus the bug slipped out without being noticed for quite a long time.
more see in Thanh's original post. Nobody followed up. What to do? I never used this, either, nor understand for what it would do good. Should we remove \pdfmovechars to close this bug?
Hi Hartmut, AFAIK, \pdfmovechars had been introduced to circumvent bugs in ancient versions of Acrobug. I never needed this and I doubt that anyone still uses such an old version. On the other hand, if the nonfree Acrobat is affected, one should not forget that some people do not have the money to upgrade whenever Adobe makes a new release. I think that Hans Hagen's opinion is quite valuable, he has the best overview. 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. ----------------------------------------------------------------------------
Hi Reinhard,
I think that Hans Hagen's opinion is quite valuable, he has the best overview.
concerning older acrobats: - on windows, 'professional' users will have an acrobat >=4, others wil have relatively new readers - on the mac, on osx there only have been versions >=6 (maybe 5) ; on system 9 ... hardly any pdftex users - on linux, this platform was supported relatively late, so those viewers are ok so, i agree with you that it we can obsolete this primitive 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 -----------------------------------------------------------------
participants (5)
-
Hans Hagen
-
Hartmut Henkel
-
noreply@sarovar.org
-
Reinhard Kotucha
-
The Thanh Han