Colleagues, some luatex revisions ago I realised that assigments to pdf_refobj nodes are ignored. The following assertion fails: \directlua{ local ref = node.new(node.id "whatsit", node.subtype "pdf_refobj") ref.objnum = 1 assert(ref.objnum) }\end By compiling and trying several revisions back, I found that it is so sice rev3229. Is the pdf_refobj whatsit intentionally not writable? By the way, due to the change of pdf metatable, assignments to pdf library table, pdf.whatever = true assert(pdf.whatever) are ignored since rev3206. That doesn't hurt, just wanted to be sure if this is acknowledged. -- Pawe/l Jackowski P.Jackowski@gust.org.pl
Paweł Jackowski wrote:
Colleagues,
some luatex revisions ago I realised that assigments to pdf_refobj nodes are ignored. The following assertion fails:
\directlua{
local ref = node.new(node.id "whatsit", node.subtype "pdf_refobj") ref.objnum = 1 assert(ref.objnum)
}\end
By compiling and trying several revisions back, I found that it is so sice rev3229. Is the pdf_refobj whatsit intentionally not writable?
i can imagine that to be on purpose as there is no other safeguard
By the way, due to the change of pdf metatable, assignments to pdf library table,
pdf.whatever = true assert(pdf.whatever)
are ignored since rev3206. That doesn't hurt, just wanted to be sure if this is acknowledged.
that's a bug then as there is no reason not to assing to the pdf table (i probably do that 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 -----------------------------------------------------------------
On Mon, 21 Dec 2009, Hans Hagen wrote:
Pawe? Jackowski wrote:
some luatex revisions ago I realised that assigments to pdf_refobj nodes are ignored. The following assertion fails:
\directlua{
local ref = node.new(node.id "whatsit", node.subtype "pdf_refobj") ref.objnum = 1 assert(ref.objnum)
}\end
By compiling and trying several revisions back, I found that it is so sice rev3229. Is the pdf_refobj whatsit intentionally not writable?
i can imagine that to be on purpose as there is no other safeguard
this should work, checking what's wrong... Regards, Hartmut
By compiling and trying several revisions back, I found that it is so sice rev3229. Is the pdf_refobj whatsit intentionally not writable?
Hartmut:
found it, i had misunderstood the meaning of "attr" in texnodes.c, it should be fixed now in SVN 3279.
Checked on 3282; pdf_refobj.objnum works ok.
Many thanks for reporting, and sorry for the trouble.
Many thanks for the fix few hours after my feedback, and me sorry for the trouble :)
pdf.whatever = true assert(pdf.whatever)
are ignored since rev3206. That doesn't hurt, just wanted to be sure if this is acknowledged.
Hans:
that's a bug then as there is no reason not to assing to the pdf table (i probably do that anyway)
OK then, reported to mantis as http://tracker.luatex.org/view.php?id=310 As since this needs touching pdf metatable anyway, two thoughts for your consideration. 1. New pdf table fields (pdf.pdftrailer, pdf.pdfinfo, pdf.pdfcatalog, pdf.pdfnames) actually do nothing more but assign internal toks lists. As we know, their pdftex equivalents weren't generic toks lists, but perhaps they should for interface consistency? And perhaps they should live in the same place as pdfpageattr and companion? 2. Fontmap-related write-only fields (pdf.mapline, pdf.mapfile) could actually be static functions pdf.mapline "+font Font ..." pdf.mapfile "pdftex.map" as there is no advantage of having them dynamic. Then one can local them local mapline = pdf.mapline avoiding unnecessary overhead of metacall on every access to pdf table. Best regards, Paweł -- Pawe/l Jackowski P.Jackowski@gust.org.pl
Paweł Jackowski wrote:
1. New pdf table fields (pdf.pdftrailer, pdf.pdfinfo, pdf.pdfcatalog, pdf.pdfnames) actually do nothing more but assign internal toks lists. As we know, their pdftex equivalents weren't generic toks lists, but perhaps they should for interface consistency? And perhaps they should live in the same place as pdfpageattr and companion?
this is on purpose as the interface at the lua end is not modelled after the one at the tex end; we will even go further and provide hooks at the lua end like pdf.writecatalog(collectedsofar) or so, i.e. even more control
2. Fontmap-related write-only fields (pdf.mapline, pdf.mapfile) could actually be static functions
pdf.mapline "+font Font ..." pdf.mapfile "pdftex.map"
as there is no advantage of having them dynamic. Then one can local them
local mapline = pdf.mapline
avoiding unnecessary overhead of metacall on every access to pdf table.
well, the whole font/map related bit of the code will be overhauled (not before 0.50) as part of other cleanup (type1c etc) but that will not happen before 0.50. The overhead you mention is neglectable (after all functions also have overhead). Hans
Hans Hagen wrote:
Paweł Jackowski wrote:
1. New pdf table fields (pdf.pdftrailer, pdf.pdfinfo, pdf.pdfcatalog, pdf.pdfnames) actually do nothing more but assign internal toks lists. [...] this is on purpose as the interface at the lua end is not modelled after the one at the tex end; we will even go further and provide hooks at the lua end like pdf.writecatalog(collectedsofar) or so, i.e. even more control
Sounds cool!
2. Fontmap-related write-only fields (pdf.mapline, pdf.mapfile) could actually be static functions [...] well, the whole font/map related bit of the code will be overhauled (not before 0.50) as part of other cleanup (type1c etc) but that will not happen before 0.50. The overhead you mention is neglectable (after all functions also have overhead).
OK, thank you. -- Pawe/l Jackowski P.Jackowski@gust.org.pl
Hi Pawe? On Mon, 21 Dec 2009, Pawe? Jackowski wrote:
some luatex revisions ago I realised that assigments to pdf_refobj nodes are ignored. The following assertion fails:
\directlua{
local ref = node.new(node.id "whatsit", node.subtype "pdf_refobj") ref.objnum = 1 assert(ref.objnum)
}\end
By compiling and trying several revisions back, I found that it is so sice rev3229. Is the pdf_refobj whatsit intentionally not writable?
found it, i had misunderstood the meaning of "attr" in texnodes.c, it should be fixed now in SVN 3279. Many thanks for reporting, and sorry for the trouble. Regards, Hartmut
participants (3)
-
Hans Hagen -
Hartmut Henkel -
Paweł Jackowski