Re: ambiguity of grammar for font shorthand?
Hi Tony, Tony Graham wrote: On Mon, Sep 21 2009 23:30:17 +0100, jonathan.levin...@intersystems.com wrote: ... If inherit is allowed to be a value then the grammar truly becomes ambiguous since each of these can have the value inherit and we don?t know which ones are omitted and must take the value normal. 'inherit' doesn't mix with other values [1]. AFAIK, this is true even for shorthands taken from CSS2. Well the point you’re referring to says that ‘inherit’ can’t be mixed with other operations in an expression. Technically speaking the shorthand is not an expression. And, anyway, the point also says that the ‘from-parent()’ function can be used instead, which leads to the same issue. That said, your point made me look at the introduction of section 7.31, “Shorthand Properties”: http://www.w3.org/TR/2006/REC-xsl11-20061205/#d0e33965 which says that “One cannot mix ‘inherit’ with other subproperty values as it would not be possible to specify the subproperty to which ‘inherit’ applied”. While this is not always true as we found out, that avoids the problem... ... Except when the ‘normal’ keyword is used, which applies to all three style/variant/weight properties, and may also lead to ambiguous values. If the value is 'inherit', the individual properties for which the shorthand is a shorthand individually inherit [2]. Regards, Tony Graham tony.gra...@menteithconsulting.com Director W3C XSL FO SG Invited Expert Menteith Consulting Ltd XML Guild member XML, XSL and XSLT consulting, programming and training Registered Office: 13 Kelly's Bay Beach, Skerries, Co. Dublin, Ireland Registered in Ireland - No. 428599 http://www.menteithconsulting.com -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- xmlroff XSL Formatter http://xmlroff.org xslide Emacs mode http://www.menteith.com/wiki/xslide Unicode: A Primer urn:isbn:0-7645-4625-2 [1] http://www.w3.org/TR/xsl11/#d0e5479 [2] http://www.w3.org/TR/xsl11/#shortexpan Vincent
When must the structure tree be output in the PDF file?
To those PDF specialists around here: am I right that the structure tree could as well be converted into PDF at the end of a page sequence, as at the beginning? In other words: could the piece of code dealing with the structure tree be moved from PDFDocumentHandler.startPageSequence to PDFDocumentHandler.endPageSequence? Thanks, Vincent
Re: ambiguity of grammar for font shorthand?
On 23/09/2009, at 8:18 PM, Vincent Hennebert wrote: Hi Tony, Tony Graham wrote: On Mon, Sep 21 2009 23:30:17 +0100, jonathan.levin...@intersystems.com wrote: ... If inherit is allowed to be a value then the grammar truly becomes ambiguous since each of these can have the value inherit and we don?t know which ones are omitted and must take the value normal. 'inherit' doesn't mix with other values [1]. AFAIK, this is true even for shorthands taken from CSS2. Well the point you’re referring to says that ‘inherit’ can’t be mixed with other operations in an expression. Technically speaking the shorthand is not an expression. And, anyway, the point also says that the ‘from-parent()’ function can be used instead, which leads to the same issue. That said, your point made me look at the introduction of section 7.31, “Shorthand Properties”: http://www.w3.org/TR/2006/REC-xsl11-20061205/#d0e33965 which says that “One cannot mix ‘inherit’ with other subproperty values as it would not be possible to specify the subproperty to which ‘inherit’ applied”. While this is not always true as we found out, that avoids the problem... When is it not true? ... Except when the ‘normal’ keyword is used, which applies to all three style/variant/weight properties, and may also lead to ambiguous values. Font shorthand implicitly sets _all_ of these values to normal, doesn't it? If the value is 'inherit', the individual properties for which the shorthand is a shorthand individually inherit [2]. Regards, Tony Graham tony.gra...@menteithconsulting.com Director W3C XSL FO SG Invited Expert Menteith Consulting Ltd XML Guild member XML, XSL and XSLT consulting, programming and training Registered Office: 13 Kelly's Bay Beach, Skerries, Co. Dublin, Ireland Registered in Ireland - No. 428599 http:// www.menteithconsulting.com -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- xmlroff XSL Formatter http:// xmlroff.org xslide Emacs mode http://www.menteith.com/wiki/ xslide Unicode: A Primer urn:isbn: 0-7645-4625-2 [1] http://www.w3.org/TR/xsl11/#d0e5479 [2] http://www.w3.org/TR/xsl11/#shortexpan Vincent
Re: When must the structure tree be output in the PDF file?
Not just like that (if at all). The content items being produced inside the page-sequence have to be linked into the structure tree. There are links (MCIDs) back and forth between the structure tree and the content streams. You have to have the structure tree available while you create the page contents to build up the links. You could probably move the generation to endPageSequence but you'd end up duplicating some of the data structures for establishing the links in the process which you'd then have to map to the PDF library in the end. Not sure if that's what you want. I don't have this stuff present as much as back when I helped Jost, so I may be missing something. On 23.09.2009 13:44:11 Vincent Hennebert wrote: To those PDF specialists around here: am I right that the structure tree could as well be converted into PDF at the end of a page sequence, as at the beginning? In other words: could the piece of code dealing with the structure tree be moved from PDFDocumentHandler.startPageSequence to PDFDocumentHandler.endPageSequence? Thanks, Vincent Jeremias Maerki
