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 Keiron Liddle <ke...@aftexsw.com> on 2000/09/16 09:36:41 UTC

inline'ing instream-foreign-object

I have worked out why instream-foreign-object was not inline and a way
to fix it.

It is a bit of a hack. When a block area is created it creates
LineArea's which only expects to have text placed inside it.
After changing it so that when a foreign object is added to the block
area it is added to the LineArea inside the text it works.

The rendering also expects the LineArea data to be text by placing the
current position where text would be drawn.

I think that it is an area that needs to be looked at. The way that FOP
handles placing and rendering inline areas. Especially the calculation
of the top and bottom of the rectangle containing all the inline areas.

I suspect that images, tables, superscript and subscript text is also
part of this.




Table in table

Posted by Palka Jaroslaw <cr...@pipeta.chemia.pk.edu.pl>.
HEEELP!!!!
I get strange effects when I'm trying to create table in table.
Something like this:

<fo:table border-width="1pt" border-color="black">
 <fo:table-column column-width="50mm"/>
 <fo:table-body>
  <fo:table-row>
   <fo:table-cell border-width="1pt" border-color="black">
    < fo:table border-width="1pt">
                ...
    </fo:table>
   </fo:table-cell>
 </fo:table-row>
 </fo:table-body>
</fo:table>

I get white space between table-cell border and inner table border, and I don't
how to erase this

--- 
OFERTA SPECJALNA 46GB DYSK TWARDY IBM 7200 OBROTOW ZA 999 PLN NETTO 
KONIECZNIE ZAJRZYJ DO NAS SUPER OFERTA http://www.idh.pl tel. 012 6321677 


Re: inline'ing instream-foreign-object

Posted by Keiron Liddle <ke...@aftexsw.com>.
Arved Sandstrom wrote:

>
> A precursor to a lot of this is ensuring that all the traits arrive at the
> areas, which is why I was pushing the phased approach, and looking at
> property refinement first. Hopefully we can still adopt that.

I agree, it is probably best to approach it in a logical order and not get
sidetracked.
I guess I am pushing from a different angle, which seems to be overlapping a
bit.
I'll leave it how it is and keep the stuff for later.

My changes correctly handle (as far as I know) the stuff in
"docs/examples/fo/instream.fo". It tests a few of the instream things.

>
> I am trying to get some docs out before the end of the month, and maybe some
> code, that pertain to all of this.
>
> Arved


Re: inline'ing instream-foreign-object

Posted by Arved Sandstrom <Ar...@chebucto.ns.ca>.
At 05:36 PM 9/16/00 +1000, Keiron Liddle wrote:
>I have worked out why instream-foreign-object was not inline and a way
>to fix it.
>
>It is a bit of a hack. When a block area is created it creates
>LineArea's which only expects to have text placed inside it.
>After changing it so that when a foreign object is added to the block
>area it is added to the LineArea inside the text it works.
>
>The rendering also expects the LineArea data to be text by placing the
>current position where text would be drawn.
>
>I think that it is an area that needs to be looked at. The way that FOP
>handles placing and rendering inline areas. Especially the calculation
>of the top and bottom of the rectangle containing all the inline areas.
>
>I suspect that images, tables, superscript and subscript text is also
>part of this.

Hi, Keiron

I haven't managed to do much because of work, but this _is_ one area (no pun 
intended) that I'm examining.

We need, I think, to be able to unambiguously identify each area mentioned 
in the spec with areas that we have in the layout package, and comment them 
as such. This includes adding (explicitly or through our inheritance 
mechanism) all the traits that the area must possess.

Once we have a clear understanding of each area in our layout package, 
including new ones, then we can fix or modify them.

A precursor to a lot of this is ensuring that all the traits arrive at the 
areas, which is why I was pushing the phased approach, and looking at 
property refinement first. Hopefully we can still adopt that.

I am trying to get some docs out before the end of the month, and maybe some 
code, that pertain to all of this.

Arved

Senior Developer
e-plicity.com (www.e-plicity.com)
Halifax, Nova Scotia
"B2B Wireless in Canada's Ocean Playground"