Bug 526273 - xmlto pdf croaks with "! Illegal unit of measure (replaced by filll)."
xmlto pdf croaks with "! Illegal unit of measure (replaced by filll)."
Product: Fedora
Classification: Fedora
Component: xmlto (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Ondrej Vasik
Fedora Extras Quality Assurance
Depends On:
Blocks: 599805
  Show dependency treegraph
Reported: 2009-09-29 11:38 EDT by Frank Ch. Eigler
Modified: 2010-06-03 16:31 EDT (History)
1 user (show)

See Also:
Fixed In Version: xmlto-0.0.23-3.fc13
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 599805 (view as bug list)
Last Closed: 2009-10-13 08:30:23 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
xml input (181.13 KB, text/xml)
2009-09-29 11:38 EDT, Frank Ch. Eigler
no flags Details

  None (edit)
Description Frank Ch. Eigler 2009-09-29 11:38:47 EDT
Created attachment 363035 [details]
xml input

Run upon attached .xml file (generated during systemtap builds),
plain "xmlto pdf" fails, but gives no useful diagnostics about
how to correct the problem.


! Illegal unit of measure (replaced by filll).
<argument> <5:block     ><5:block       >L
                                ogging Tapset</5:block></5:block>\@empty 
l.3398 .../fo:block><fo:block break-before="page">
                                                  <fo:block id="API-warn"><f...

! Emergency stop.
<argument> <5:block     ><5:block       >L
                                ogging Tapset</5:block></5:block>\@empty 
l.3398 .../fo:block><fo:block break-before="page">
                                                  <fo:block id="API-warn"><f...

!  ==> Fatal error occurred, no output PDF file produced!
Transcript written on tmp.log.
Comment 1 Ondrej Vasik 2009-09-29 13:49:18 EDT
Thanks for report, will check it. Likely passivetex issue, will check what could be done with this. It's great that at least dblatex backend is able to process it, passivetex is very old and has many limitations.
Comment 2 Ondrej Vasik 2009-09-29 16:42:53 EDT
Yep, likely something fragile in passivetex. When I removed(in fact just commented out) full chapter "logging.stp" , pdf built just fine even with passivetex. I'll check what's wrong/different with that section.
Comment 3 Ondrej Vasik 2009-10-01 04:55:30 EDT
Generating pdf with fop and dblatex is ok, fo is generated properly, no memory/stack/level limit within tetex basic configuration is reached. Something is wrong with that one chapter, generating pdf failed there even if I moved that chapter "logging.stp" up (to aproximately half of the tapsets.xml). Reassigning to passivetex (which is still my package, so it doesn't matter). I'll try to check tex output and compare what's wrong with tex code of that chapter.
Comment 4 Ondrej Vasik 2009-10-13 08:30:23 EDT
Fine, could be workarounded by xmlto, so fixed there (as I don't want to waste time with analyzing passivetex sty file). It seems that passivetex can't handle chapter titles starting with L if they have refentry(s) inside. Patching pdf/dvi/ps format script to enter newlines after "block>" entries seems to solve (workaround) the issue. Fixed in xmlto-0.0.23-3.fc13, closing RAWHIDE.

Note You need to log in before you can comment on or make changes to this bug.