[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug #62934] gropdf: sometimes \(em becomes a different char when render
From: |
Deri James |
Subject: |
[bug #62934] gropdf: sometimes \(em becomes a different char when rendered with gropdf |
Date: |
Mon, 22 Aug 2022 12:02:54 -0400 (EDT) |
Update of bug #62934 (project groff):
Status: None => Need Info
_______________________________________________________
Follow-up Comment #1:
This is a remapping issue. If glyphs have a code point above 255 they have to
be remapped to a lower number which is not in use, but if the code it is
mapped to belongs to a glyph which is used later in the document, then that
original glyph needs to be mapped to another unused code as well, this is
remapping.
If you run groff with -P-d flag the pdf contains debugging information. Useful
information can be gained by using the command "egrep -a 'AAA|MMM'
broken.pdf". This is what is produced:-
% AAA Assign u0420 (304) to 10
% AAA Assign u0430 (362) to 11
% AAA Assign u0437 (572) to 12
% AAA Assign u043D (485) to 13
% AAA Assign u043E (581) to 14
% AAA Assign u0431 (565) to 15
% AAA Assign u0440 (402) to 16
% AAA Assign u044B (355) to 17
% AAA Assign u0438_0306 (535) to 18
% AAA Assign u0438 (433) to 19
% AAA Assign u0433 (277) to 20
% AAA Assign u0442 (404) to 21
% AAA Assign u043F (518) to 22
% AAA Assign u0432 (426) to 23
% AAA Assign u043C (444) to 24
% AAA Assign u0447 (516) to 25
% AAA Assign u043B (583) to 26
% AAA Assign u0441 (568) to 27
% AAA Assign u0435 (554) to 28
% AAA Assign u0434 (336) to 29
% AAA Assign u0444 (434) to 30
% AAA Assign u044E (493) to 31
% AAA Assign u0446 (477) to 127
% AAA Assign u0443 (539) to 145
% AAA Assign u044C (500) to 160
At this point all the /undef glyphs have been used up, now look for glyphs
between 128-255 which have not been already "used" (flag in glyph structure
USED).
% AAA Assign u0448 (338) to 128
% AAA Assign u0445 (555) to 129
% AAA Assign u044F (340) to 130
% AAA Assign u043A (401) to 131
% AAA Assign u0449 (290) to 132
% AAA Assign u0436 (437) to 133
% AAA Assign u0410 (390) to 134
% AAA Assign u042F (414) to 135
% AAA Assign u0411 (318) to 136
% AAA Assign u044A (509) to 137
% AAA Assign u041A (566) to 138 <-- 138 is code point for \(em
% AAA Assign u044D (264) to 146
% AAA Assign em (138) to 147 <-- we have an \(em but its position has been
taken by \[u041a]
% MMM Remap 138 to 147 <-- So choose code 147 for \(em instead
% AAA Assign u0412 (260) to 147 <-- Here's the bug, 147 is \(em now, so it
should be USED (but isn't!!)
% AAA Assign u0421 (496) to 148
% AAA Assign u041F (463) to 149
% AAA Assign u041C (447) to 150
% AAA Assign u0414 (502) to 151
% AAA Assign u0435_0308 (548) to 152
% AAA Assign a" (147) to 153 <-- Another \(em but it doesn't match current
occupant so gets remapped again.
% MMM Remap 147 to 153
So it is clear that when the first \[em] is received and it is mapped to 147
the USED flag is not being set, since the next glyph which needs moving uses
147 as well. This patch fixes the issue (for me, please test).
--- gropdf 2022-08-22 15:07:10.218388264 +0100
+++ /usr/bin/gropdf 2022-08-22 15:02:47.293997392 +0100
@@ -3772,6 +3772,7 @@
my $glyph=$fnt->{NO}->[$unused]->[1];
delete($fontlst{$cft}->{CACHE}->{$cftsz});
$fnt->{NAM}->{$chnm}->[ASSIGNED]=$unused;
+ $fnt->{NAM}->{$chnm}->[USED]=1;
$fnt->{NO}->[$unused]->[1]=$chnm;
$widtbl=CacheWid($cft);
The reason your good version works is because the first use of \[em] happens
before codepoint 138 is assigned one of the cyrillic glyphs, so the USED flag
has already been set, preventing it being used for mapping.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?62934>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
- [bug #62934] gropdf: sometimes \(em becomes a different char when rendered with gropdf, Nikita Ivanov, 2022/08/21
- [bug #62934] gropdf: sometimes \(em becomes a different char when rendered with gropdf,
Deri James <=
- [bug #62934] gropdf: sometimes \(em becomes a different char when rendered with gropdf, Deri James, 2022/08/22
- [bug #62934] gropdf: sometimes \(em becomes a different char when rendered with gropdf, Nikita Ivanov, 2022/08/22
- [bug #62934] [gropdf] sometimes \(em becomes a different char when rendered, G. Branden Robinson, 2022/08/23
- [bug #62934] [gropdf] sometimes \(em becomes a different char when rendered, G. Branden Robinson, 2022/08/23
- [bug #62934] [gropdf] sometimes \(em becomes a different char when rendered, Deri James, 2022/08/23
- [bug #62934] [gropdf] sometimes \(em becomes a different char when rendered, G. Branden Robinson, 2022/08/23
- [bug #62934] [gropdf] sometimes \(em becomes a different char when rendered, Deri James, 2022/08/23
- [bug #62934] [gropdf] sometimes \(em becomes a different char when rendered, G. Branden Robinson, 2022/08/23
- [bug #62934] [gropdf] sometimes \(em becomes a different char when rendered, Dave, 2022/08/23
- [bug #62934] [gropdf] sometimes \(em becomes a different char when rendered, Deri James, 2022/08/23