xmlroff-list — xmlroff XSL formatter discussion list

Re: [xmlroff] Hugly PDF output

[Tim W. <tw...@re...>]

On Thu, Mar 10, 2005 at 10:23:19AM +0100, pca...@ca... wrote:

> It looks like that the pages are just images embedded in PDF therefore
> the files are big, the text cannot be copied/paste and it is not
> possible to search text inside the document. I am using xpdf to display
> pdf files.

I'm using xpdf to display an xmlroff-generated PDF file, and searching
for text works fine.

xpdf-3.00, xmlroff-0.3.2.

Tim.
*/

Re: [xmlroff] Hugly PDF output

[Tony G. <Ton...@Su...>]

pca...@ca... writes:
> Sorry for the rough subject but this is really important to me.
>
> I have been playing the whole day yesterday with XMLroff and was very
> pleased by the results even if it is still beta.
> I was very pleased until I had a look at the generated PDF file which
> looked like very big compared to the amount of text inside the document.
>
> It looks like that the pages are just images embedded in PDF therefore
> the files are big, the text cannot be copied/paste and it is not
> possible to search text inside the document. I am using xpdf to display
> pdf files.
>
> Is this a bug or a feature?
>
> Is it due to the backend and will it evolve or not in the future?

I think you'll find that most of the PDF file is embedded fonts, not
graphic images of the text.

Unfortunately, I don't know how to tell gnome-print to not embed
fonts, which is good for reproducible output but not so good for
producing small-size files (as you have seen).

Have you tried copying and pasting text from xmlroff output?

It's not something that I usually do, but I did just try it with the
DocBook sample that Tim Waugh sent yesterday and got complete
gibberish:

   8MXPI 8EFPI SJ 'SRXIRXW 7IGXMSR XMXPI 7IGXMSR XMXPI 4EVEKVETL

(It does appear to be a cipher of what it should be, not that that
makes it useful for anything.)

Is that what you were referring to?

Regards,


Tony.

[xmlroff] instream-foreign-object SVG?

[Julian R. <gn...@th...>]

Hi,

  What are your thoughts on supporting SVG instream-foreign-objects?  I have
been thinking that would be a cool longer-term goal, and an itch that I'd
eventually like to scratch.  I was doing a bit of reading - there's this
librsvg associated with GNOME which dumps GdkPixBufs; when I googled svg to
postscript, I found a discussion on an XSL-FO mailing list about the subject
which you were part of (you mentioned xslfo-proc -> now dandy - I couldn't
really tell what its deal is from its website) - but you guys seemed to be
saying "hmm that should be pretty easy but is there such a tool?" or "maybe
people will start using SVG as a page description language instead of PS or
PDF".
  I'm sure you have ideas about the subject - what are they?  I'm not trying
to jump into a huge undertaking after just submitting a couple patches - just
getting excited about a possible longer term goal.  Would an SVG "rendering"
library on top of gnome-print make any sense?  BTW I still have little to no
idea what I'm talking about regarding most of these things - so feel free to
tell me I'm being stupid.

  Thanks,
   Julian

[xmlroff] Hugly PDF output

[<pca...@ca...>]

Hi!

Sorry for the rough subject but this is really important to me.

I have been playing the whole day yesterday with XMLroff and was very
pleased by the results even if it is still beta.
I was very pleased until I had a look at the generated PDF file which
looked like very big compared to the amount of text inside the document.

It looks like that the pages are just images embedded in PDF therefore
the files are big, the text cannot be copied/paste and it is not
possible to search text inside the document. I am using xpdf to display
pdf files.

Is this a bug or a feature?

Is it due to the backend and will it evolve or not in the future?

Thanks,

Phil.

Re: [xmlroff] ...->sprintf (...)

[Tim W. <tw...@re...>]

On Wed, Mar 09, 2005 at 03:50:49PM +0000, Tony Graham wrote:

> While 'sprintf' is actually not evocative, or descriptive, or easily
> rolling off the tongue, it is well known.  Would gcc complain if it
> was '->sprintf_func'?  Are there any other suggestions for a name?

Actually, changing this:
  ...->sprintf (...)
to this:
  (...->sprintf) (...)

is enough to stop the macro expansion.

Tim.
*/

Re: [xmlroff] [patch] libfo-compat.xsl and significant space

[Tony G. <Ton...@Su...>]

Tim Waugh <tw...@re...> writes:
> Here is a patch to fix significant space handling in
> libfo-compat.xsl.  This preserves spaces between text nodes and (for
> example) fo:inline nodes.

Thanks, but instead I added <xsl:preserve-space> and listed all the
FOs with #PCDATA in their content model.  Please confirm whether or
not that does the job.

I did check in your region-body patch.  Thank you for that.

The next question is what to do about the 'unsupported property'
warning messages.  The attributes representing the unsupported
properties could be stripped by libfo-compat.xsl, or the
FoLibfoContext warning mode setting could actually be implemented.
For the moment, it is easier to add them to libfo-compat.xsl as
alternatives in the '@height' template rule.

Regards,


Tony.

[xmlroff] [patch] libfo-compat.xsl and significant space

[Tim W. <tw...@re...>]

Here is a patch to fix significant space handling in
libfo-compat.xsl.  This preserves spaces between text nodes and (for
example) fo:inline nodes.

Tim.
*/

--- /usr/share/xml/libfo-0.3.1/libfo-compat.xsl	2005-03-09 15:21:42.000000000 +0000
+++ libfo-compat.xsl	2005-03-09 19:20:11.000000000 +0000
@@ -75,7 +75,13 @@
   </xsl:template>
 
   <xsl:template match="text()">
+    <xsl:if test="contains(' &#xA;',substring(.,1,1))">
+      <xsl:text> </xsl:text>
+    </xsl:if>
     <xsl:value-of select="normalize-space()"/>
+    <xsl:if test="contains(' &#xA;',substring(.,string-length(),1))">
+      <xsl:text> </xsl:text>
+    </xsl:if>
   </xsl:template>
 
   <xsl:template match="@border">

Re: [xmlroff] DocBook FO stylesheet for xmlroff?

[Tim W. <tw...@re...>]

I managed to get some output (hurray!) by adding this bit to the
libfo-compat.xsl style sheet:

--- /usr/share/xml/libfo-0.3.1/libfo-compat.xsl	2005-03-09 15:21:42.000000000 +0000
+++ libfo-compat.xsl	2005-03-09 17:51:33.000000000 +0000
@@ -579,6 +579,12 @@
     <xsl:apply-templates/>
   </xsl:template>
 
+  <xsl:template match="fo:region-body/@region-name">
+    <xsl:if test="$verbose">
+      <xsl:message>Removing 'fo:region-body' region-name attribute.</xsl:message>
+    </xsl:if>
+  </xsl:template>
+
   <xsl:template match="fo:float">
     <xsl:if test="$verbose">
       <xsl:message>Removing unsupported 'fo:float'.</xsl:message>

Tim.
*/

Re: [xmlroff] DocBook FO stylesheet for xmlroff?

[Tim W. <tw...@re...>]

On Wed, Mar 09, 2005 at 04:41:36PM +0000, Tony Graham wrote:

> Please provide 'test.fo'.

Attached.  It comes from docbook-xsl-1.68.1 processing this input:

==>
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
 "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" [

]>

<article id="index" lang="en">
  <articleinfo>
    <title>Title</title>
  </articleinfo>

  <sect1>
    <title>Section title</title>
    <para>Paragraph.</para>
  </sect1>
</article>
<==

Tim.
*/

Re: [xmlroff] DocBook FO stylesheet for xmlroff?

[Tony G. <Ton...@Su...>]

Tim Waugh <tw...@re...> writes:
> On Wed, Mar 09, 2005 at 04:00:41PM +0000, Tony Graham wrote:
>> It's called 'libfo-compat.xsl' and should be installed when you
>> install xmlroff.
>
> I spotted that just after I sent my message.  Unfortunately it didn't
> get me very far. :-(
>
> $ xmlto fo test.xml
> Making portrait pages on A4 paper (210mmx297mm)
> $ xsltproc /usr/share/xml/libfo-0.3.1/libfo-compat.xsl test.fo > compat.fo
> $ xmlroff compat.fo
>
> (process:27677): libfo-WARNING **: Warning: fo-result-to-fo-error-quark: Unsupported property: font-selection-strategy
> ...
> [other warnings like this]
...
> libfo-ERROR **: area_size_request:: parent is NULL
> aborting...

Please provide 'test.fo'.

Regards,


Tony.

[xmlroff] xmlroff-list also available as digest

[Tony G. <Ton...@Su...>]

The recent flurry of messages may be more than you've come to expect
from the xmlroff-list.  If so, there's always the option of receiving
the xmlroff-list as a daily digest.

For instructions on changing your SourceForge mailing lists'
preferences, see:

https://sourceforge.net/docman/display_doc.php?docid=12983&group_id=1#preferences

There may one day be a case for splitting the xmlroff-list into, say,
a technical list and an annoucements list, but I don't think we're
there yet.

Regards,


Tony.

Re: [xmlroff] DocBook FO stylesheet for xmlroff?

[Tim W. <tw...@re...>]

On Wed, Mar 09, 2005 at 04:00:41PM +0000, Tony Graham wrote:

> It's called 'libfo-compat.xsl' and should be installed when you
> install xmlroff.

I spotted that just after I sent my message.  Unfortunately it didn't
get me very far. :-(

$ xmlto fo test.xml
Making portrait pages on A4 paper (210mmx297mm)
$ xsltproc /usr/share/xml/libfo-0.3.1/libfo-compat.xsl test.fo > compat.fo
$ xmlroff compat.fo

(process:27677): libfo-WARNING **: Warning: fo-result-to-fo-error-quark: Unsupported property: font-selection-strategy
...
[other warnings like this]
...
(process:27677): libfo-CRITICAL **: Expression evaluation error: Evaluation resulted in an error
Object path: /FoTree[1]/root[1]/layout-master-set[1]/simple-page-master[20]/region-body[1]
...
(process:27677): libfo-WARNING **: Unsupported property: (null)
...
(process:27677): libfo-CRITICAL **: fo_region_body_get_writing_mode: assertion `fo_region_body != NULL' failed

(process:27677): libfo-CRITICAL **: fo_region_body_area_new: assertion `fo != NULL' failed

(process:27677): libfo-CRITICAL **: fo_area_set_generated_by: assertion `fo_area != NULL' failed

(process:27677): libfo-CRITICAL **: fo_area_page_add_child: assertion `child != NULL' failed

(process:27677): libfo-CRITICAL **: fo_node_parent: assertion `fo_node != NULL' failed

libfo-ERROR **: area_size_request:: parent is NULL
aborting...

Tim.
*/

Re: [xmlroff] DocBook FO stylesheet for xmlroff?

[Tim W. <tw...@re...>]

On Wed, Mar 09, 2005 at 10:51:40AM -0500, Stefan Seefeld wrote:

> I'm not sure that this is an easy task.
> However, I agree that docbook-to-pdf processing provides a nice
> (and wildly popular) use case. In this light, would it be possible
> to set up a benchmark, i.e. turning the test suite into a progress
> meter so people can see how xmlroff gets closer to that goal ?

I think that once it is possible to process DocBook documents at all
using xmlroff, it will become apparent quite quickly which bits are
missing.  Hopefully this will speed up the rate at which developers
discover and contribute to xmlroff. :-)

There is an interesting file shipped with xmlroff:

/usr/share/xml/libfo-0.3.1/libfo-compat.xsl

Unfortunately, I tried applying that stylesheet to a
docbook-xsl-generated XSL-FO file but didn't notice much difference in
the warnings and errors generated.

The particular sorts of DocBook documents I'm interested in getting
xmlroff going with are the Fedora Core documentation manuals. (These
actually contain a subset of DocBook tags, not the full set.)

Tim.
*/

Re: [xmlroff] DocBook FO stylesheet for xmlroff?

[Tony G. <Ton...@Su...>]

Tim Waugh <tw...@re...> writes:
> On Wed, Mar 09, 2005 at 03:26:46PM +0000, Tony Graham wrote:
...
>> Thank you for your interest in providing and using
>> the RPM spec files.  Can you now verify whether the patch below adds
>> the incantation in the right place?
>
> Yes, that looks right.

Thanks.  The fix is in CVS and will be in the next PangoXSL release.

Regards,


Tony.

Re: [xmlroff] DocBook FO stylesheet for xmlroff?

[Tony G. <Ton...@Su...>]

Tim Waugh <tw...@re...> writes:
> On Wed, Mar 09, 2005 at 03:26:46PM +0000, Tony Graham wrote:
...
> I've not been following xmlroff very much until just recently I'm
> afraid, what with other commitments.  I'm now looking at it again to
> see what it can do now that it couldn't last time I looked. :-)
>
> I realise that it can't process the docbook-xsl FO stylesheet output
> yet, but I was wonder if it's possible to make a simple stylesheet for
> DocBook to XSL-FO that xmlroff *would* be able to process, either
> right now or in the not too distant future.
>
> What do you think?

It's called 'libfo-compat.xsl' and should be installed when you
install xmlroff.

It munges or drops stuff that xmlroff doesn't yet support.  It's
really just a rename of the stylesheet I did to get output from the
samples from the XML 2003 XSL-FO town hall and is still a bit too
specific to those samples (down to matching values of some shorthands
used in the samples).

Patches to libfo-compat.xsl would be accepted.

Regards,


Tony.

Re: [xmlroff] DocBook FO stylesheet for xmlroff?

[Stefan S. <se...@sy...>]

Tim Waugh wrote:

> I've not been following xmlroff very much until just recently I'm
> afraid, what with other commitments.  I'm now looking at it again to
> see what it can do now that it couldn't last time I looked. :-)
> 
> I realise that it can't process the docbook-xsl FO stylesheet output
> yet, but I was wonder if it's possible to make a simple stylesheet for
> DocBook to XSL-FO that xmlroff *would* be able to process, either
> right now or in the not too distant future.
> 
> What do you think?

I'm not sure that this is an easy task.
However, I agree that docbook-to-pdf processing provides a nice
(and wildly popular) use case. In this light, would it be possible
to set up a benchmark, i.e. turning the test suite into a progress
meter so people can see how xmlroff gets closer to that goal ?

Sorry, I'v ment to help a bit with the testing infrastructure before.
May be I could look into this ?

Regards,
		Stefan

Re: [xmlroff] ...->sprintf (...)

[Tony G. <Ton...@Su...>]

Tim Waugh <tw...@re...> writes:
> I just tried compiling xmlroff 0.3.2 and I got this error:
>
> fo-object.c: In function 'fo_object_sprintf':
> fo-object.c:251: error: 'struct _FoObjectClass' has no member named
> '__builtin___sprintf_chk'
> fo-object.c:251: error: syntax error before ')' token
>
> It's because sprintf is a macro (I have -D_FORTIFY_SOURCE=2 in my
> CFLAGS).
>
> Names of C functions that may be implemented as macros cannot be used
> as user functions or variables, and that includes this struct member.
>
> I think it needs to be changed to something other than 'sprintf'.

But 'sprintf' is such an evocative but descriptive name that just
rolls off the tongue so easily!

While 'sprintf' is actually not evocative, or descriptive, or easily
rolling off the tongue, it is well known.  Would gcc complain if it
was '->sprintf_func'?  Are there any other suggestions for a name?

Regards,


Tony.

[xmlroff] DocBook FO stylesheet for xmlroff?

[Tim W. <tw...@re...>]

On Wed, Mar 09, 2005 at 03:26:46PM +0000, Tony Graham wrote:

> I'm afraid that RPM spec files are just voodoo to me (and not my
> favourite form of voodoo at that).  If it weren't for you, we wouldn't
> have them at all.=20

Heh :-)

> Thank you for your interest in providing and using
> the RPM spec files.  Can you now verify whether the patch below adds
> the incantation in the right place?

Yes, that looks right.

I've not been following xmlroff very much until just recently I'm
afraid, what with other commitments.  I'm now looking at it again to
see what it can do now that it couldn't last time I looked. :-)

I realise that it can't process the docbook-xsl FO stylesheet output
yet, but I was wonder if it's possible to make a simple stylesheet for
DocBook to XSL-FO that xmlroff *would* be able to process, either
right now or in the not too distant future.

What do you think?

Tim.
*/

Re: [xmlroff] pangoxsl-devel RPM needs .so file

[Tony G. <Ton...@Su...>]

Tim Waugh <tw...@re...> writes:
> I just got a link error from rebuilding xmlroff 0.3.2, and it was due
> to the pangoxsl RPM spec file missing this line in the file manifest
> for the devel package:
>
> %{_libdir}/*.so

I'm afraid that RPM spec files are just voodoo to me (and not my
favourite form of voodoo at that).  If it weren't for you, we wouldn't
have them at all.  Thank you for your interest in providing and using
the RPM spec files.  Can you now verify whether the patch below adds
the incantation in the right place?

Regards,


Tony.


Index: pangoxsl.spec.in
===================================================================
RCS file: /cvsroot/pangopdf/pangoxsl/pangoxsl.spec.in,v
retrieving revision 1.2
retrieving revision 1.3
diff -r1.2 -r1.3
58a59
> %{_libdir}/*.so
63a65,67
> * Wed Mar 09 2005 Tony Graham <ton...@us...>
> - Added missing *.so to 'files devel' (Tim Waugh)
> 

[xmlroff] pangoxsl-devel RPM needs .so file

[Tim W. <tw...@re...>]

Hi,

I just got a link error from rebuilding xmlroff 0.3.2, and it was due
to the pangoxsl RPM spec file missing this line in the file manifest
for the devel package:

%{_libdir}/*.so

Tim.
*/

Re: [xmlroff] ...->sprintf (...)

[Tim W. <tw...@re...>]

..alternatively perhaps there should be a #undef sprintf somewhere.

Tim.
*/

[xmlroff] ...->sprintf (...)

[Tim W. <tw...@re...>]

Hi,

I just tried compiling xmlroff 0.3.2 and I got this error:

fo-object.c: In function 'fo_object_sprintf':
fo-object.c:251: error: 'struct _FoObjectClass' has no member named
'__builtin___sprintf_chk'
fo-object.c:251: error: syntax error before ')' token

It's because sprintf is a macro (I have -D_FORTIFY_SOURCE=2 in my
CFLAGS).

Names of C functions that may be implemented as macros cannot be used
as user functions or variables, and that includes this struct member.

I think it needs to be changed to something other than 'sprintf'.

Tim.
*/

Re: [xmlroff] 'border-style' and 'border-width' properties

[Julian R. <gn...@th...>]

Hi,

> >   It looks like I've got border-style and border-width working, at least judging
> > by a couple tests.
> 
> Can you send me your test files, too, so I can add them to the xmlroff
> test suite?

  I'm afraid they're not worthy.  I was just messing with the shorthand and
non-shorthand border attributes on a single fo:block and seeing whether it was
behaving as expected.
  I'm happy to do some work on the test suite.  I'm thinking it may be better
to wait until I've ingested more of the spec, though, so that I have a better
idea what exactly I should be testing for.

  Thanks,
    Julian

Re: [xmlroff] 'border-style' and 'border-width' properties

[Tony G. <Ton...@Su...>]

Julian Rosse <gn...@th...> writes:
>   It looks like I've got border-style and border-width working, at least judging
> by a couple tests.

Can you send me your test files, too, so I can add them to the xmlroff
test suite?

>> The easiest way would be to submit the patch for
>> spec-dump/dump-info.xml and a separate patch for xmlroff/fo-context.c
>> and xmlroff/fo-context{-private}?.h.
>> 
>> Since the properties' files are new, I'll just merge your
>> dump-info.xml patch, make the properties' files, and copy them over.
>
>   I had to manually edit the new properties' .c files to change the validate
> function to check if it's a tblr (rather than the default set of validation
> type checks) - I copied this from fo-property-border-color.c.  So I should
> send you at least the .c files, unless you want to make this change to each
> by hand.

Patches would be good.

>   In terms of sending patches, what is the easiest/best way to do that?  Can
> you create a patch that applies to multiple files?  Just do "cvs diff file1
> file2 ..."?  Above you seem to be implying a certain way of splitting up the

If the only changes you've made to the source are for 'border-width'
and 'border-style', then just 'cvs diff' should be sufficient.

> patches.  I also edited property/fo-property-eval.c and
> property/fo-all-property.h (patching in relevant lines from spec-dump's
> "make fo-all-property-h-dump") in addition to the above-mentioned dump-info.xml,
> fo-context-*, the below-mentioned property/Makefile.am, and the new
> properties' .c files (their .h files as dumped by spec-dump are ok, I guess - 
> I didn't touch them).  And then the property resolution code in
> fo_context_util_border_resolve() in fo-context-util.c.
> I think that's it.  So I guess I'm asking: for those
> files, what's the best way to submit patches to you?

One patch file for the 'xmlroff' module and one for the 'spec-dump'
module.

You can send them straight to me.

>> I have modified 'dump-info.xml' to reduce the differences.
>> 
>> I also added support for a 'expr-eval' attribute on <property>
>> elements in dump-info.xml so there'll be one less piece of manual
>> fixup on the generated files.
>
>   Cool; I used the expr-eval attribute, using your new
> fo_expr_border_style_eval() for border-style and fo_expr_padding_eval() as
> you recommended for border-width.  I also set the resolve-enum attributes
> to the same thing that the individual border-style/border-width properties
> have for that attribute - I was sort of copying what you did for border-color
> and am not sure whether these resolve-enum attributes are entirely correct/
> necessary.

The validation code for FoTblr property values really should call a
validation routine for each of its component values, but obviously it
doesn't yet.

The functions named in the resolve-enum should be called at some point
as part of validating the FoTblr property values because they do
things like convert the 'medium' border-width enumeration token into a
length.  The whole resolve-enum and validate functions machinery was
set up for the non-shorthand properties and hasn't caught up with the
fact that we also do shorthands.

The resolve-enum functions are also part of the context for evaluating
a property value expression.  Evaluating the 'border' property will
probably require a resolve-enum function that just calls the three
resolve-enums for the three components to see if any of them can
resolve the enumeration token.

Suggestions on how to improve it would be welcome.

>   Another thing - in my test cases, when I used "border-width", it gave me
> a number of warning messages equal to the number of tokens in border-width's
> value about datatype != NULL failing in fo_expr_context_push_stack().  Looking
> at eval_border_style_expr(), I'm pretty sure you just have an extra
>
> fo_expr_context_push_stack (context, intermediate_value);

I'll look at it once I have running code.  Thanks for pointing it out.

> where you don't want it - it looks like eval_enum() actually does the
> pushing earlier in the function and intermediate_value doesn't get set if
> parse_ncname() succeeds, thus the error indicating that intermediate_value
> is NULL.  It was working nonetheless, I guess because eval_enum() was
> successfully pushing the tokens onto the stack, but letting you know.

Thanks for doing this work.

Regards,


Tony.

[xmlroff] 'border-style' and 'border-width' properties

[Julian R. <gn...@th...>]

Hi,
  It looks like I've got border-style and border-width working, at least judging
by a couple tests.

> The easiest way would be to submit the patch for
> spec-dump/dump-info.xml and a separate patch for xmlroff/fo-context.c
> and xmlroff/fo-context{-private}?.h.
> 
> Since the properties' files are new, I'll just merge your
> dump-info.xml patch, make the properties' files, and copy them over.

  I had to manually edit the new properties' .c files to change the validate
function to check if it's a tblr (rather than the default set of validation
type checks) - I copied this from fo-property-border-color.c.  So I should
send you at least the .c files, unless you want to make this change to each
by hand.
  In terms of sending patches, what is the easiest/best way to do that?  Can
you create a patch that applies to multiple files?  Just do "cvs diff file1
file2 ..."?  Above you seem to be implying a certain way of splitting up the
patches.  I also edited property/fo-property-eval.c and
property/fo-all-property.h (patching in relevant lines from spec-dump's
"make fo-all-property-h-dump") in addition to the above-mentioned dump-info.xml,
fo-context-*, the below-mentioned property/Makefile.am, and the new
properties' .c files (their .h files as dumped by spec-dump are ok, I guess - 
I didn't touch them).  And then the property resolution code in
fo_context_util_border_resolve() in fo-context-util.c.
I think that's it.  So I guess I'm asking: for those
files, what's the best way to submit patches to you?

> I have modified 'dump-info.xml' to reduce the differences.
> 
> I also added support for a 'expr-eval' attribute on <property>
> elements in dump-info.xml so there'll be one less piece of manual
> fixup on the generated files.

  Cool; I used the expr-eval attribute, using your new
fo_expr_border_style_eval() for border-style and fo_expr_padding_eval() as
you recommended for border-width.  I also set the resolve-enum attributes
to the same thing that the individual border-style/border-width properties
have for that attribute - I was sort of copying what you did for border-color
and am not sure whether these resolve-enum attributes are entirely correct/
necessary.

  Another thing - in my test cases, when I used "border-width", it gave me
a number of warning messages equal to the number of tokens in border-width's
value about datatype != NULL failing in fo_expr_context_push_stack().  Looking
at eval_border_style_expr(), I'm pretty sure you just have an extra

fo_expr_context_push_stack (context, intermediate_value);

where you don't want it - it looks like eval_enum() actually does the
pushing earlier in the function and intermediate_value doesn't get set if
parse_ncname() succeeds, thus the error indicating that intermediate_value
is NULL.  It was working nonetheless, I guess because eval_enum() was
successfully pushing the tokens onto the stack, but letting you know.

  Thanks,
    Julian