Follow-up Comment #4, bug#65098 (group groff):
Red Tree
========
I assume you have built my branch at some point, any Titian hues?
Special Pleading (MR)
=====================
You were correct I was bending a general case to try to fit a special case.
For Iterator
============
I can see many uses for this mechanism. One of my design goals for the new
gropdf was to allow non-latin languages to use groff to use all the pdf
features available to latin languages, particular using the currently
available fonts which cover a wide range of languages. The size of these fonts
are huge so the current practice of embedding the entire font is probably a
non-starter, hence the need for subsetting and being able to use more than 256
glyphs from the font.
Part of this requires unicode to be passed to gropdf, to cater for code such
as:-
.pdfbookmark 1 "Chinese text"
Preconv will have converted the chinese text to a group of \[uXXXX] which in
turn is converted by troff to nodes, so the for loop will set N for each
chinese character and I end up with an empty string. The same problem occurs
if chinese is used to set a named destination within the pdf, but it is worse
because the destination name is also used in the pdf:look array and if each
call results in the empty string, it will not work.
So, I have a few doubts it will completely remove the need for stringhex, but
you may find a way.
Cheers
Deri
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?65098>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
