You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Clay Leeds <cl...@medata.com> on 2003/03/07 19:09:16 UTC

Additions to FOP/LIMITATIONS page

Howdy,

I was looking at the FOP Limitations page, came to the conclusion that 
some of the FAQ-type questions could be resolved on the LIMITATIONS 
and/or Implemented page. A couple which come to mind are:

- Using page-number-citation for "Page x of n" using the  ol'
   <fo:page-number/> of <fo:page-number-citation ref-id="endofdoc"/>
   combined with a <fo:block id="endofdoc"/> at the end of the
   fo:region-body trick
- keep-together.* only works on fo:table-row
- padding="xpt" mainly applies to background-color for fo:block
   (or is it fo:table-cell I don't recall)

...there may be others, as well...

(correct my above assumptions if I'm wrong ;-)

I realize these answers are already answered in the FAQ, but the FAQ may 
be rather intimidating, weighing in at 91.26 KB (93453 bytes) of mostly 
text (with 30+ PageDowns at 1024x768, it was at first to me, anyway). If 
a FAQ relates directly to a limitation, it might make sense and be 
easier to find if it's on the limitations page. I'm not advocating 
making the Limitations and/or Implemented pages into 90K+ FAQ pages. 
Rather, I'm just trying to lighten the load of FAQs from fop-user (not 
to mention fop-dev ;-).

BTW, IIRC, fo:table requires table-layout="fixed". However, on the 
/fop/limitations.html example, it's missing that. I seem to recall 
*not* having that attribute in a table once, and it gave a warning to 
the effect that it was required and assumed table-layout="fixed" for me 
(FOP is such a nice chap!). Does FOP do that (assume the obvious, tell 
me about it, and slap my wrist) in other places as well?
-- 
Clay Leeds - cleeds@medata.com
Web Developer - Medata, Inc. - http://www.medata.com
PGP Public Key: https://mail.medata.com/pgp/cleeds.asc


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org


Re: Additions to FOP/LIMITATIONS page

Posted by "J.Pietschmann" <j3...@yahoo.de>.
Clay Leeds wrote:
> I've found that occasionally text-align="center|right" doesn't always 
> work the way I expect (often displacing the text by one or two &#160;). 
If you have a space at the end of the text, like
      <fo:block >
        REDUCTION
      </fo:block>
the space will be appended to the line and cause misalignment for
centering and right alignment.
Use
      <fo:block >REDUCTION</fo:block>
instead. The fo:inline works too, because then the whitespace after
the inline is somehow dropped. This is partly due to the "improper
line breaking" I quoted.
Mind you, the spec isn't really clear whether spaces at the end of
a block are dropped by default (the relevant part is probably the
"omit-at-line-break" trait which causes spaces to be stripped when
text breaks across lines, however, it is not really spelled out
whether the beginning and the end of a block have to be considered
a line break for this purpose too).

> also, vertical-align and it's horizontal brother text-align appear to 
> only be functional with text.
They should work for inline graphic too. A graphic is, unfortunately,
always aligned a bit odd (I think "top"), so you should only inline
images which are roughly of the line height or smaller. The only
values recognized for vertical-align are sub and super, everything
else from section 7.13 is completely ignored.

>> - no handling of different font sizes within the same line
Try
  <fo:block font-size="10pt">foo <fo:wrapper font-size="30pt">bar
    </fo:wrapper></fo:block>

> It seems like many/most of these would find a good home in the 
> limitations page. So, what's keeping these jewels of information (which 
> surely must be annoying the bejeebers out of some developers) out of the 
> public eye?
Mainly because the list changes frequently and nobody cares
whether it is up to date. An outdated limitations list can be
even more annoying than none at all.
Also, long lists of feaures are better for publicity than long lists
of misfeatures. And most people wouldn't notice anything anyway, no
need to scare them away.

J.Pietschmann


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org


Re: Additions to FOP/LIMITATIONS page

Posted by Clay Leeds <cl...@medata.com>.
J.Pietschmann wrote:
> You'd be amazed how many known limitations are missing from
> the limitations page:

Judging by the length of this list (and the "quality" of some of 
these... ;-), you're right. I am amazed.

   <snip>

I've found that occasionally text-align="center|right" doesn't always 
work the way I expect (often displacing the text by one or two &#160;). 
In these instances, I've found that placing text inside of a problematic 
fo:block, inside a fo:inline, fixes the problem. Here's a sample of 
where I had to do this:

   <fo:table-cell text-align="right" display-align="center" 
padding-bottom="1pt" padding-top="2pt">
     <fo:block color="#ffffff" display-align="center" font-weight="bold">
       <fo:inline text-align="right" 
display-align="center">REDUCTION</fo:inline>
     </fo:block>
   </fo:table-cell>

   <snip>

> - no proper vertical alignment in lines, most of the values aren't
>   recognized

also, vertical-align and it's horizontal brother text-align appear to 
only be functional with text.

> - no handling of different font sizes within the same line

That may be true (you should know!), but I use the following to decrease 
the whitespace between two words (while retaining something of a "nowrap"):

   <fo:inline font-weight="bold">Adjustor<fo:inline 
font-size="4pt">&#160;</fo:inline>ID:</fo:inline>

   <snip>

> This does not include the elements and properties well known
> to be "not implemented"  as well as small bugs on the other end of
> the spectrum, like referring to ids on table cell can cause NPEs.

It seems like many/most of these would find a good home in the 
limitations page. So, what's keeping these jewels of information (which 
surely must be annoying the bejeebers out of some developers) out of the 
public eye?

Anyway, thanks for the "highlights"! I've appropriately "flagged" your 
message as a place to look when I need to know why something I'm 
expecting to work isn't actually working. ;-)
-- 
Clay Leeds - cleeds@medata.com
Web Developer - Medata, Inc. - http://www.medata.com
PGP Public Key: https://mail.medata.com/pgp/cleeds.asc


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org


Re: Additions to FOP/LIMITATIONS page

Posted by "J.Pietschmann" <j3...@yahoo.de>.
Clay Leeds wrote:
> - Using page-number-citation for "Page x of n" using the  ol'
>   <fo:page-number/> of <fo:page-number-citation ref-id="endofdoc"/>
>   combined with a <fo:block id="endofdoc"/> at the end of the
>   fo:region-body trick
This is a FO trick, hardly anything related to limitations.

> BTW, IIRC, fo:table requires table-layout="fixed". However, on the 
> /fop/limitations.html example, it's missing that.
You'd be amazed how many known limitations are missing from
the limitations page:
- dropped Text if inline FOs fall near page boundaries
- dropped lines if inline images and other elements cause
   page breaks
- fo:inline is basically ineffective, can only be used as property
   holder like fo:wrapper
- fo:character lacks basically all features you'd want to use it for
- no proper vertical alignment in lines, most of the values aren't
   recognized
- no handling of different font sizes within the same line
- linefeed-treatment not implemented
- whitespace-treatment not implemented
- improper line breaking
- improper hyphenation
- no implementation for the advanced hyphenation controls
- no reparenting for markers after retrival
- retrieve-marker-position only really works to
   first-starting-within-page and occasionally for
   last-ending-within-page, everything else is pure coincidence
- retrieval of wrong markers in case page rendering is deferred
- footnotes are not broken correctly
- footnotes don't mix well with multi-column layout
- leaders may be misaligned (even after the recent fixes)
- conditional spaces and borders are not implemented
- margins are not properly implemented
- forced page breaking is not properly implemented
- the space resolution algorithm mandated by the spec is not
   implemented
- collapsed table borders are not properly implemented
- row spanning cells can cause interesting effects, use with care
This does not include the elements and properties well known
to be "not implemented"  as well as small bugs on the other end of
the spectrum, like referring to ids on table cell can cause NPEs.

> Does FOP do that (assume the obvious, tell me 
> about it, and slap my wrist) in other places as well?
Yes, sometimes.

J.Pietschmann


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org