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 2002/08/12 11:46:37 UTC
Tasks - layout
Now that we have some pagination there are lots of areas that people can
work on.
If you want to implement any of these and have any questions then just
ask.
Once we can get a few of these done then we could do a developers
release.
- Add static areas to page
The static areas will need to be handled in a similar way to the flow
except the bpd is unlimited and it will need to reset and repeat for
each page.
- Add id areas to page when area added
When the layout managers add an area to the page it can also add the id
information.
- Resolve id references on other pages, extensions
When an id is added to a page this will allow id references to be
resolved.
- Add markers to page when areas added
When an area is added that is created by an FO that contains markers
then the markers can also be added. There are four types of positions
for markers.
- Retrieve markers from page
When doing the static areas the markers wil need to be available for
retrieving. The marker can then be layed out as normal.
- calculate line height
The line height needs to be calculated while finding breaks. This needs
to include all the alignment and height details of the inline areas.
- Various inline objects
Page number, page number citation etc. need to be implemented.
- Implement page caching
If a page need to be stored for the store pages or waiting to resolve
forward references then we need a cache mechanism to save the page
somewhere.
- Implement table layout
The table layout will use the same technique as the block layout. It
will locate suitable breaks between rows or inside rows until table
finished or end of bpd reached.
- Implement list layout
The list layout like the table layout will be looking for suitable
breaks from the child objects. The it will add the appropriate areas to
the area tree.
- Get bookmark extension working
Make sure the extension id references are resolved. Once the data is
fully resolved then implement a way for the pdf renderer to add the
bookmarks. See branch for code how to add bookmarks.
These are just some of the things, I will add them to the todo list.
If there is a decent response then there are more that can be added.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Tasks - layout
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Keiron Liddle wrote:
> Of course, but how can we make it understandable.
The problems I had
- I was not able to follow the control flow. Too many
classes/instances involved in even a few lines of
code, too many indirections through custom iterators.
I had to insert a few dumpStack(), which I did only
once before (in Excalibur of course).
- Too many classes in general.
- Deep inheritance trees.
- Parallel object/inheritance trees.
- The state of some important objects is smeared across
classes in the inheritance tree as well as auxillary
classes.
- Inconsistent and in some cases plainly misleading
packages.
- A few misleading comments.
- Distracting style issues.
Some hints to possibly improve it:
- Will layout managers ever be about something else that
break possibilities? If not, discard the BPLayoutManager
and the AbstractBPLayoutManager from the hierarchy.
(Otherwise, why is LeafNodeLayoutManager not directly
derived from AbstractLayoutManager?)
- Will positions ever be used to indicate something
else that break possiblities? If not, use BreakPoss
and LeafBreakPoss and NonLeafBreakPoss instead. This
way it should also be possible to get rid of
BreakPossPosIterator.
- In general, encapsulate iterators otherwise, at
least do not use them in method signatures as parameters.
- Do something about the responsibilities of
StructureHandler, AreaTree and Renderer.
- In general, don't be too greedy and derive a class from
another to inherit a few short methods. Dont overuse
inheritance for code reuse.
- Make methods abstract if they are abstract instead of
providing an empty implementation (resetPosition() in
particular).
>>I took a stab at the static content layout and ...
..it does not work, because BlockLayoutManager inherits
the no-op implementation of resetPosition() from
Abstract...whatever...LayoutManager. Therefore, the
block(s) in the static content are never reset, and
the content is only printed on the first page :-(
This should be easy to fix for you.
>>Actually, how is "unlimited" expressed in MinOptMax terms?
> I could imagine that it might adjust to the size of the region. So if
> larger it uses min value etc.
Static content is laid out after the main flow, so the
page viewport should already have been adjusted to the
real page if necessary.
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Tasks - layout
Posted by Keiron Liddle <ke...@aftexsw.com>.
On Sun, 2002-08-18 at 02:07, J.Pietschmann wrote:
> Keiron Liddle wrote:
> > I don't think we should expect or even want people to understand
> > everything.
>
> I think it's preferable that people hacking around in the
> code understand *something*.
Of course, but how can we make it understandable.
> I took a stab at the static content layout and even get
Great!
> some text but AcrobatReader complains about "Font not
> set" if there is static content. Also, the static content
> is always rendered into the upper left cornder, regardless
> which region it should be in. Meanwhile I'm completely
> out of ideas where to look, especially for the font issue.
Since each region is in its own graphics state the font needs to be set
at a higher state of for the text in each region. The problem was that
the last font state was kept from the last region.
The regions seem to be put in the right place for me, maybe the viewer
got an error so stopped doing things properly.
> Actually, how is "unlimited" expressed in MinOptMax terms?
> Stuffing in a "large number" doesn't strike me as very clean.
> I settled for the page BPD, under the assuption that the
> page viewport would not exceed this.
I'm not sure.
I could imagine that it might adjust to the size of the region. So if
larger it uses min value etc.
> J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
How to display a text which contains '&' ?
Posted by Amerin Szulr <pr...@yahoo.com>.
Hi
I want the wording ' E&O.E ' to be printed on every page.
<fo:static-content flow-name="xsl-region-after">
<fo:block font-size="9pt" text-align="end">
E&O.E
</fo:block>
</fo:static-content>
By using the above code , i can able to print text without '&' . If i use '&' its searchig for an entity and i'm getting the following error.
D:\FOP\fop-0.20.4rc>FOP -xsl surrenderValueXsl.xsl -xml surrenderValueXml.xml -p
df surrenderValuepdf.pdf
D:\FOP\fop-0.20.4rc>java -cp build\fop.jar;lib\batik.jar;lib\xalan-2.3.1.jar;lib
\xercesImpl-2.0.1.jar;lib\xml-apis.jar;lib\avalon-framework-cvs-20020315.jar;lib
\logkit-1.0.jar;lib\jimi-1.0.jar org.apache.fop.apps.Fop -xsl surrenderValueXsl.
xsl -xml surrenderValueXml.xml -pdf surrenderValuepdf.pdf
[INFO] FOP 0.20.4rc
[Fatal Error] surrenderValueXsl.xsl:42:10: The reference to entity "O.E" must en
d with the ';' delimiter.
[ERROR] null
Any Help ? Thnx in advance.
---------------------------------
Do You Yahoo!?
HotJobs, a Yahoo! service - Search Thousands of New Jobs
Re: Tasks - layout
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Keiron Liddle wrote:
> I don't think we should expect or even want people to understand
> everything.
I think it's preferable that people hacking around in the
code understand *something*.
I took a stab at the static content layout and even get
some text but AcrobatReader complains about "Font not
set" if there is static content. Also, the static content
is always rendered into the upper left cornder, regardless
which region it should be in. Meanwhile I'm completely
out of ideas where to look, especially for the font issue.
> No for a static area all areas are placed into the static region. So
> that the block progression dimension is unlimited. The clipping and
> overflow determine what happens when rendering the things outside the
> viewport.
Actually, how is "unlimited" expressed in MinOptMax terms?
Stuffing in a "large number" doesn't strike me as very clean.
I settled for the page BPD, under the assuption that the
page viewport would not exceed this.
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Tasks - layout
Posted by Keiron Liddle <ke...@aftexsw.com>.
On Wed, 2002-08-14 at 22:06, J.Pietschmann wrote:
> Keiron Liddle wrote:
> > - Add static areas to page
> > The static areas will need to be handled in a similar way to the flow
> > except the bpd is unlimited and it will need to reset and repeat for
> > each page.
>
> I looked at it. Is static content supposed to be handled
> by a FlowLayoutManager too? It seems a bit too specialized
> to a fo:flow to me.
I would think it would be another class but quite the same.
It does the same thing except it doesn't find breaks it just adds all
areas.
> I think I understand now why the design of HEAD is as
> it is now. I still think there are better possibilities,
> perhaps deriving classes representing FOs from layout
> manager classes, thereby avoiding communication between
> the objects representing FOs and the associated layout
> managers.
I want A solution, the current one is the closest we have right now.
> Does anybody dare to apply an OO metric to HEAD? Deeply
> nested inheritance trees, lots of communications from
> everywhere to everywhere... I'd bet the complexity is
> just a notch below "for supergeniuses only", which would
> nicely fit the unusual long time it took me to grasp
> why *anything* is laid out at all.
I haven't noticed lots of communication everywhere to everywhere, most
of it is single direction or single purpose.
The layout context and break possibility make things a bit confusing.
The complexity of the layout means that a lot of this is necessary.
I don't think we should expect or even want people to understand
everything. In a way understanding the layout *is* understanding the
spec except it is done in a particular way.
> And:
> > except the bpd is unlimited
> You mean "limited", do you?
No for a static area all areas are placed into the static region. So
that the block progression dimension is unlimited. The clipping and
overflow determine what happens when rendering the things outside the
viewport.
> J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Tasks - layout
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Keiron Liddle wrote:
> - Add static areas to page
> The static areas will need to be handled in a similar way to the flow
> except the bpd is unlimited and it will need to reset and repeat for
> each page.
I looked at it. Is static content supposed to be handled
by a FlowLayoutManager too? It seems a bit too specialized
to a fo:flow to me.
I think I understand now why the design of HEAD is as
it is now. I still think there are better possibilities,
perhaps deriving classes representing FOs from layout
manager classes, thereby avoiding communication between
the objects representing FOs and the associated layout
managers.
Does anybody dare to apply an OO metric to HEAD? Deeply
nested inheritance trees, lots of communications from
everywhere to everywhere... I'd bet the complexity is
just a notch below "for supergeniuses only", which would
nicely fit the unusual long time it took me to grasp
why *anything* is laid out at all.
And:
> except the bpd is unlimited
You mean "limited", do you?
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
RE: Tasks - layout
Posted by Arved Sandstrom <Ar...@chebucto.ns.ca>.
> -----Original Message-----
> From: J.Pietschmann [mailto:j3322ptm@yahoo.de]
> Sent: August 24, 2002 9:03 AM
> To: fop-dev@xml.apache.org
> Subject: Re: Tasks - layout
>
> Thanks for the quick answers!
>
> Arved Sandstrom wrote:
[ SNIP ]
> > Other possible related issue to consider - footnotes are
> sometimes gathered
> > as notes at the end of a document, rather than appearing in the
> midst of the
> > document. Could this be a configurable thing?
> This could be easily achieved with XSLT, instead of generating to
> footnotes inline, gather them at the end with a moded template
> or something. I don't think it's something XSLFO should care for.
Yeah, you're right.
AHS
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
RE: Tasks - layout
Posted by Arved Sandstrom <Ar...@chebucto.ns.ca>.
> -----Original Message-----
> From: J.Pietschmann [mailto:j3322ptm@yahoo.de]
> Sent: August 24, 2002 9:03 AM
> To: fop-dev@xml.apache.org
> Subject: Re: Tasks - layout
>
> Arved Sandstrom wrote:
[ SNIP ]
> >>- Same for out-of-line FOs, in particular footnotes (->Error).
> > Floats with class 'xsl-before-float' must be placed into region-body
> > according to the spec, so this is an error. As far as side-floats go, no
> > error at all, AFAIK. They work just fine.
> I meant, what about forced breaks in floats and footnotes?
Ahh, OK, I had misunderstood. Thought you were talking about multicolumn.
The notes for "break-after" (Section 7.19.1; although oddly enough, not the
notes for "break-before", Section 7.19.2) specifically state that the effect
of a break is to dictate what happens with _normal_ areas generated by the
FO in question. I'd assume that both the breaks obey this.
My gut feeling is that the XSL 1.0 intentions for breaks only consider
normal areas. Breaks state that certain areas shall be leading or trailing
in context areas, and normal areas are the only ones for which we can say
that they are leading or trailing. So breaks in floats & footnotes are
ignored. That being said, it's perfectly possible to think of reasonable
behaviour for a break in a side-float, as an extension.
Arved
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Tasks - layout
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Thanks for the quick answers!
Arved Sandstrom wrote:
> Both the footnote-reference-area and the
> before-float-reference-area span all columns; they have the same IPD as the
> main-reference-area. See Section 6.10.1.3.
I looked in section 4...
> Other possible related issue to consider - footnotes are sometimes gathered
> as notes at the end of a document, rather than appearing in the midst of the
> document. Could this be a configurable thing?
This could be easily achieved with XSLT, instead of generating to
footnotes inline, gather them at the end with a moded template
or something. I don't think it's something XSLFO should care for.
>>- Same for out-of-line FOs, in particular footnotes (->Error).
> Floats with class 'xsl-before-float' must be placed into region-body
> according to the spec, so this is an error. As far as side-floats go, no
> error at all, AFAIK. They work just fine.
I meant, what about forced breaks in floats and footnotes?
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Tasks - layout
Posted by "Peter B. West" <pb...@powerup.com.au>.
Arved,
Comments below.
Arved Sandstrom wrote:
>>From: J.Pietschmann [mailto:j3322ptm@yahoo.de]
...
>>- How should forced breaks be handled in static content (->Error)?
>
>
> Warning or error depending on strictness. Oddly enough the spec appears not
> to anticipate this possibility.
>
>
>>- Same for out-of-line FOs, in particular footnotes (->Error).
>
>
> Floats with class 'xsl-before-float' must be placed into region-body
> according to the spec, so this is an error. As far as side-floats go, no
> error at all, AFAIK. They work just fine.
Are we talking about break-(before/after) defined on, say, fo:blocks
within a side-float? You're saying that such a break would force the
generation of a new side-float reference-area of area-class
xsl-side-float on the next page?
I hadn't thought about this, but it has some interesting consequences.
fo:float is not allowed specific dimensions; the dimensions are derived
from the contents. That seems to mean, e.g., that if a side float
contains a number of fo:blocks, and these have no specified IPDim, that
the effective IPDim of the float is the maximum of the IPDims of the
blocks, when their contents are laid out as a single line.
This "intrinsic width" constraint is very useful. It allows the
side-float to be laid out independently when encountered, with no IPDim
and possibly the current understanding of the remaining BPDim. That
BPDim itself is not fixed, because there may be, say, footnotes in the
flow before the end of page is reached.
If the independently laid-out side-float reports back its maximum IPDim
and BPDim, the layout of the rest of the page can proceed around it. If
the reported BPDim allows the float to fit neatly within the page
layout, the region-body layout process accepts the initial areas from
the side-float layout process, which then terminates (unless it has its
own break-* conditions, and has only so far laid out up to the break).
If the side-float is forced to break, however, the region-body layout
gives the float layout a BPDim. This, of course, has the potential to
reduce the IPDim of the float. so we have yet another convergence
problem. E.g., the float may contain a graphical element, followed by
explanatory text. The dimensions of the graphic are intrinsic, and the
text is enclosed in a block-container with a certain IPDim, which may be
smaller or larger than IPDim of the graphic. The text doesn't all fit
on the page, and the float is forced to break.
The overall logic is familiar from other situations.
Do a tenatative layout with limited or no dimension information.
Report back on the results.
Accept requests for another layout with new or more constrained
dimension information.
Accept OK. Terminate or do the next bit.
All of the convergence and pathology resolution happens at some higher
level, although in general the process can be recursive.
Peter
--
Peter B. West pbwest@powerup.com.au http://www.powerup.com.au/~pbwest/
"Lord, to whom shall we go?"
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
RE: Tasks - layout
Posted by Arved Sandstrom <Ar...@chebucto.ns.ca>.
> -----Original Message-----
> From: J.Pietschmann [mailto:j3322ptm@yahoo.de]
> Sent: August 23, 2002 5:02 PM
> To: fop-dev@xml.apache.org
> Subject: Re: Tasks - layout
>
[ SNIP ]
> BTW: how are footnotes supposed to be laid out if there
> are columns in the body? Does the footnote area span
> all columns, or should it get only one column?
The XSL Requirements Summary (http://www.w3.org/TR/WD-XSLReq) describes this
problem as non-trivial. :-) Implementations have variously gone with
footnotes that span all columns, or wrap within one column.
In XSL 1.0 it is specified. Both the footnote-reference-area and the
before-float-reference-area span all columns; they have the same IPD as the
main-reference-area. See Section 6.10.1.3.
> Another interesting problem: what happens if a footnote
> on the last page does not fit the page? Possible
> approaches:
> - Move the line and the footnote to the next page.
> Problem: could leave a large empty space.
> - Render the footnote as usual and break it to the next
> page.
> Problems
> o Must render footnote separator, which may look ugly.
> o Put the footnote area at the top or at the bottom
> of the otherwise empty page?
First approach preferable, I'd say: perfectly OK by the spec to move to
subsequent pages, including the first block returned by the footnote-body.
Other possible related issue to consider - footnotes are sometimes gathered
as notes at the end of a document, rather than appearing in the midst of the
document. Could this be a configurable thing?
> Other issues I'm to lazy to look up in the spec (if they are
> mentioned at all):
> - How should forced breaks be handled in static content (->Error)?
Warning or error depending on strictness. Oddly enough the spec appears not
to anticipate this possibility.
> - Same for out-of-line FOs, in particular footnotes (->Error).
Floats with class 'xsl-before-float' must be placed into region-body
according to the spec, so this is an error. As far as side-floats go, no
error at all, AFAIK. They work just fine.
> - How are before-floats handled in case there are columns (same
> as footnotes)?
Yes, same as footnotes. See above.
[ SNIP ]
Regards,
AHS
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Tasks - layout
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Karen Lease wrote:
>> I agree, the BP letters don't really add much information now anyway.
>>
> Now we just need to decide who does it to avoid stepping on each other's
> toes.
What about using a BreakPOsition hierarchy instaed of
Positions and a BreakPossiblity?
>> I was thinking that it could return a break only if it is better
>> or the same or if past the end.
>> This way a block would only have one break position most of the time.
>>
>>
> That sounds about like what Joerg said too. Let's start with that and then
> refine it if necessary when we get into more complex layout situations.
There are complicating matters: out of line FOs.
In particular, floats cause probably a re-layout of
previous stuff, and footnotes reduce the available
space for the stack.
I think if an out of line FO is discovered, this should
be noted and cause higher level LM to take action.
BTW: how are footnotes supposed to be laid out if there
are columns in the body? Does the footnote area span
all columns, or should it get only one column?
Another interesting problem: what happens if a footnote
on the last page does not fit the page? Possible
approaches:
- Move the line and the footnote to the next page.
Problem: could leave a large empty space.
- Render the footnote as usual and break it to the next
page.
Problems
o Must render footnote separator, which may look ugly.
o Put the footnote area at the top or at the bottom
of the otherwise empty page?
Other issues I'm to lazy to look up in the spec (if they are
mentioned at all):
- How should forced breaks be handled in static content (->Error)?
- Same for out-of-line FOs, in particular footnotes (->Error).
- How are before-floats handled in case there are columns (same
as footnotes)?
Next subject: I had an extended look at list-block layout.
I think list-block as well as list-item-label and
list-item-body can get an ordinary BlockLayoutManager (for
list-block, a simplyfied subclass of BlockParentLM suffuces).
The interesting stuff is in the LM for list-item. It has to
manage two stacks, for the label ans the body. I think
it gets a BP for the first, then iterates for the other
stack until its size exceeds the size of the first, then
switch etc. a BP is if the MinOptMax intervals for both
stacks overlap. clearly, the MinMax for the BP is the
intersection of the stack's intervals, the interesting
point is how to calculate the Opt. Possibilities:
- arithmetic mean, then clip on result MinMax
- clip either Opt on the result MinMax, then take the
mean
- some other mean.
- whatever
Yet another subject: reset()
I have problems to grasp why there is a reset(Position)
and a resetPosition(Position). Can someone enlighten me
what the differences are? Furthermore, the reset() of
AbstractBPLM has a potential problem:
if (m_curChildLM != lm) {
...
while (m_curChildLM != lm && m_childLMiter.hasPrevious()) {
m_curChildLM.resetPosition(null);
m_curChildLM = (BPLayoutManager) m_childLMiter.previous();
}
m_childLMiter.next(); // Otherwise next returns same object
If the position passed was null, and the first LM was current
the iterator would set to the second, wich is wrong and would
probably cause the second child to be omitted. I think the
LMiter.next() should only be called if there was actually
previous() executed. Maybe it would help to really have
a reset() (without arguments) which resets a LM to the very
start.
Have a nice weekend.
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Tasks - layout
Posted by "Peter B. West" <pb...@powerup.com.au>.
Karen Lease wrote:
> Keiron Liddle wrote:
>>> Another general LM issue involves at which level to take into account
>>> the stacksize limit. For the inline stuff, I only used it at the
>>> LineLM level. I just had the lower level LM return each possible
>>> line-end and then let the LineLM decide whether it fit or not. When
>>> it got a BreakPoss which was too big, it could then decide to
>>> hyphenate, which means going into a kind of mode where it examines
>>> less optimal breaks.
>>>
>>> The equivalent of that logic on the block stacking level could be to
>>> have all block-level LM except the FlowLM return fairly large chunks
>>> (between block-level FOs for example) and then have the FlowLM ask
>>> them to break the block into smaller pieces when it gets a BreakPoss
>>> which overflows the current column size. I was originally thinking of
>>> having the block-level LM return on every Line, but that makes a lot
>>> of work and a lot of object creation, so it would probably be slow.
>>>
>>
>> I was thinking that it could return a break only if it is better
>> or the same or if past the end.
>> This way a block would only have one break position most of the time.
>>
>>
> That sounds about like what Joerg said too. Let's start with that and then
>
> refine it if necessary when we get into more complex layout situations.
Karen,
I am reading this discussion with interest even though I don't know the
code and don't follow the details. When I was thinking about these
issues in terms of galleys, it seemed to me that the galley processor
had to be able to do conditional or absolute layout depending on the
request made of it and the information given. If the IPDim and the
remaining BPDim are known, the galley processor can just go ahead and
either exhaust itself or fill the remainder of the page and suspend
pending a new page. In the case of the dreaded auto table layout, each
galley within a table cell must report minimum and maximum IPDim; i.e.
it must consider every break possibility. These values bubble back and
are consolidated into column minima and maxima, and the results of those
calculations will be sent back as a fixed IPDim.
FWIW, I would tackle auto table layout first. If you can do that, the
other situations should be simplifications, and there is no question
that your framework can handle them.
Peter
--
Peter B. West pbwest@powerup.com.au http://www.powerup.com.au/~pbwest/
"Lord, to whom shall we go?"
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Tasks - layout
Posted by Karen Lease <kl...@club-internet.fr>.
A few comments below.
Keiron Liddle wrote:
<snip/>
> I worked out some alignment and ipd adjustment things. This look like it
> can work in a similar way.
> There is one tricky part, the ipd of the text parts accumulate. This means
> that to find the total ipd of a line break it needs to add the last ipd
> of each layout manager.
>
Yes, this is indeed a tricky part. I ended up storing the total IPD for the last BreakPoss
returned by each layout manager (in any given parent area) in order to keep this straight.
That's the hashtable whose key is the LM. It gets complicated in backup
conditions, but it seemed to be working. However, I'm not real proud of
that code.
>
>>Now that it looks like things are heating up, we probably do need to do
>>some cleanup before we get too much more code written. I agree with
>>Joerg that we could simplify the inheritance now that we are only using
>>the BP stuff. It wouldn't be so much work at this point to fold the BP
>>versions back into the original interface and AbstractLM and to rename
>>LineBP and TextBP. What do you think?
>>
>
> I agree, the BP letters don't really add much information now anyway.
>
Now we just need to decide who does it to avoid stepping on each other's toes.
<snip/>
>
>>Another general LM issue involves at which level to take into account
>>the stacksize limit. For the inline stuff, I only used it at the LineLM
>>level. I just had the lower level LM return each possible line-end and
>>then let the LineLM decide whether it fit or not. When it got a
>>BreakPoss which was too big, it could then decide to hyphenate, which
>>means going into a kind of mode where it examines less optimal breaks.
>>
>>The equivalent of that logic on the block stacking level could be to
>>have all block-level LM except the FlowLM return fairly large chunks
>>(between block-level FOs for example) and then have the FlowLM ask them
>>to break the block into smaller pieces when it gets a BreakPoss which
>>overflows the current column size. I was originally thinking of having
>>the block-level LM return on every Line, but that makes a lot of work
>>and a lot of object creation, so it would probably be slow.
>>
>
> I was thinking that it could return a break only if it is better
> or the same or if past the end.
> This way a block would only have one break position most of the time.
>
>
That sounds about like what Joerg said too. Let's start with that and then
refine it if necessary when we get into more complex layout situations.
-Karen
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Tasks - layout
Posted by Keiron Liddle <ke...@aftexsw.com>.
On Wed, 2002-08-21 at 23:29, Karen Lease wrote:
> Hi Keiron,
>
> Keiron Liddle wrote:
>
> <snip/>
> >
> > The line height calculation and alignment is only very basic at the moment.
> > The idea is that the LineLM gets certain information to find the offset to
> > baseline and total line height and when the InlineLM add areas they use this
> > information to set the position of the inline areas.
> >
> >
> Yes, I noticed that you'd added this as well to the information returned in the BreakPoss.
I worked out some alignment and ipd adjustment things. This look like it
can work in a similar way.
There is one tricky part, the ipd of the text parts accumulate. This means
that to find the total ipd of a line break it needs to add the last ipd
of each layout manager.
> Now that it looks like things are heating up, we probably do need to do
> some cleanup before we get too much more code written. I agree with
> Joerg that we could simplify the inheritance now that we are only using
> the BP stuff. It wouldn't be so much work at this point to fold the BP
> versions back into the original interface and AbstractLM and to rename
> LineBP and TextBP. What do you think?
I agree, the BP letters don't really add much information now anyway.
> The other thing I have been thinking about is how to structure the
> information we are returning in BreakPoss (besides the actual position
> part). In fact, it's really the same (more or less) information which
> we'll end up putting on the final Area we create, since a BreakPoss is
> really just a potential Area. I was wondering a while back whether we
> should just encapsulate an Area directly in the BreakPoss and use that
> to store the size information. On the other hand, some information won't
> be needed on the final areas (once they are positioned) such as the
> MinOptMax space around the area, the keep constraints etc, which are
> only used by the LayoutManagers while decided which BreakPoss to
> actually use to create the Area.
I think this needs to come out from the functionality. If there is too
much on the area tree it will need to cleared at some stage.
> Another general LM issue involves at which level to take into account
> the stacksize limit. For the inline stuff, I only used it at the LineLM
> level. I just had the lower level LM return each possible line-end and
> then let the LineLM decide whether it fit or not. When it got a
> BreakPoss which was too big, it could then decide to hyphenate, which
> means going into a kind of mode where it examines less optimal breaks.
>
> The equivalent of that logic on the block stacking level could be to
> have all block-level LM except the FlowLM return fairly large chunks
> (between block-level FOs for example) and then have the FlowLM ask them
> to break the block into smaller pieces when it gets a BreakPoss which
> overflows the current column size. I was originally thinking of having
> the block-level LM return on every Line, but that makes a lot of work
> and a lot of object creation, so it would probably be slow.
I was thinking that it could return a break only if it is better
or the same or if past the end.
This way a block would only have one break position most of the time.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Tasks - layout
Posted by Karen Lease <kl...@club-internet.fr>.
J.Pietschmann wrote:
> Karen Lease wrote:
>
>> ..., since a BreakPoss is really just a potential Area.
>
>
> Just nitpicking: It is the state of a LM tree, and in that sense
> certainly a bit more than a potential area.
>
>> The equivalent of that logic on the block stacking level could be to
>> have all block-level LM except the FlowLM return fairly large chunks
>> (between block-level FOs for example) and then have the FlowLM ask
>> them to break the block into smaller pieces when it gets a BreakPoss
>> which overflows the current column size. I was originally thinking of
>> having the block-level LM return on every Line, but that makes a lot
>> of work and a lot of object creation, so it would probably be slow.
>
>
> I'm not sure whether a lot of object creation has to take place.
> Anyway, why not pass the stack size to the block and let it return
> if it *has* to break, and let the parent ask for earlier breaks
> only if this does not reconcile well with other conditions, for
> example when reconciling breaks in the cells of a table row or
> for list items.
That sounds like a plausible approach. In general, I think of the
various layout managers as implementing a particular strategy for laying
out the FO tree. There can be simple minded implementations as well as
more complex ones. For example, a smarter LineLayoutManager could
implement a TeX-like algorithm to find the best set of break positions
over a whole block of text instead of trying to optimize over a single
line. There are obviously analogies in the block level layout managers.
-Karen
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Tasks - layout
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Karen Lease wrote:
> ..., since a BreakPoss is
> really just a potential Area.
Just nitpicking: It is the state of a LM tree, and in that sense
certainly a bit more than a potential area.
> The equivalent of that logic on the block stacking level could be to
> have all block-level LM except the FlowLM return fairly large chunks
> (between block-level FOs for example) and then have the FlowLM ask them
> to break the block into smaller pieces when it gets a BreakPoss which
> overflows the current column size. I was originally thinking of having
> the block-level LM return on every Line, but that makes a lot of work
> and a lot of object creation, so it would probably be slow.
I'm not sure whether a lot of object creation has to take place.
Anyway, why not pass the stack size to the block and let it return
if it *has* to break, and let the parent ask for earlier breaks
only if this does not reconcile well with other conditions, for
example when reconciling breaks in the cells of a table row or
for list items.
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Tasks - layout
Posted by Karen Lease <kl...@club-internet.fr>.
Hi Keiron,
Keiron Liddle wrote:
<snip/>
>
> The line height calculation and alignment is only very basic at the moment.
> The idea is that the LineLM gets certain information to find the offset to
> baseline and total line height and when the InlineLM add areas they use this
> information to set the position of the inline areas.
>
>
Yes, I noticed that you'd added this as well to the information returned in the BreakPoss.
Now that it looks like things are heating up, we probably do need to do
some cleanup before we get too much more code written. I agree with
Joerg that we could simplify the inheritance now that we are only using
the BP stuff. It wouldn't be so much work at this point to fold the BP
versions back into the original interface and AbstractLM and to rename
LineBP and TextBP. What do you think?
The other thing I have been thinking about is how to structure the
information we are returning in BreakPoss (besides the actual position
part). In fact, it's really the same (more or less) information which
we'll end up putting on the final Area we create, since a BreakPoss is
really just a potential Area. I was wondering a while back whether we
should just encapsulate an Area directly in the BreakPoss and use that
to store the size information. On the other hand, some information won't
be needed on the final areas (once they are positioned) such as the
MinOptMax space around the area, the keep constraints etc, which are
only used by the LayoutManagers while decided which BreakPoss to
actually use to create the Area.
Another general LM issue involves at which level to take into account
the stacksize limit. For the inline stuff, I only used it at the LineLM
level. I just had the lower level LM return each possible line-end and
then let the LineLM decide whether it fit or not. When it got a
BreakPoss which was too big, it could then decide to hyphenate, which
means going into a kind of mode where it examines less optimal breaks.
The equivalent of that logic on the block stacking level could be to
have all block-level LM except the FlowLM return fairly large chunks
(between block-level FOs for example) and then have the FlowLM ask them
to break the block into smaller pieces when it gets a BreakPoss which
overflows the current column size. I was originally thinking of having
the block-level LM return on every Line, but that makes a lot of work
and a lot of object creation, so it would probably be slow.
For tables, I'd be tempted to always have the first layout pass return
only breaks at row boundaries (or groups of rows linked by spanning
cells) and only get into row-breaking logic if a) the row doesn't fit
and there is no previous "good" break; b) the row and its cells don't
have keep-together=always.
Of course, if we get a row or a row group which is already starting a
page and still won't fit, we have to break it anyway (or overflow it) in
order to avoid the infinite loop problem.
As you and Joerg were discussing the other day, exactly how to do the
breaking in the row is very complex. If we try to optimize it we will
get into some very deep decision trees with breaks in each cell.
I tend to think that most tables should be set up to have
keep-together=always. (Hint to the users!) On the other hand, there are
cases where people are using tables to get some kind of special layout
effect (unequal columns for example) and they want the cells to be able
to be broken, so we can't get around this in the long run.
Regards,
Karen
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Tasks - layout
Posted by Keiron Liddle <ke...@aftexsw.com>.
Hi Karen,
On Mon, 2002-08-19 at 23:57, Karen Lease wrote:
> Hi Keiron etc,
>
> I'm really happy to see all this movement going on and folks from the
> "maintenance" branch getting into the redesign to help you out. I'm
> hoping to be able to start contributing again too, perhaps not right
> away, but hopefully in September. There may even be some possibility of
> getting to work on FOP as part of my "real" work, though it might be
> hard to work on the new layout in that context. I'll keep the group posted.
Sounds good.
> I'll start by looking at the latest and then maybe cogitating on list or
> table layout, depending on the timing and what others are interested in
> doing. It looks like status.xml is the sign-up sheet for the tasks; is
> that right?
Yes, the status is keeping track of things.
Which reminds me there are some missing entries for Kevin and Rhett and
some others who are working on certain areas.
> With regard to the line-height calculations, is anybody in the group
> interested in getting into the gory details of the baseline stuff for
> different scripts? I spent some time poring over the spec and trying to
> get a handle on this, but maybe it's too much detail for now. On the
> other hand, I'd really like to make sure that this version of FOP
> handles that stuff correctly as well as being able to do the various
> kinds of line-stacking strategies defined by the XSL-FO spec.
Plenty of tricky things in that area.
The line height calculation and alignment is only very basic at the moment.
The idea is that the LineLM gets certain information to find the offset to
baseline and total line height and when the InlineLM add areas they use this
information to set the position of the inline areas.
> Regards,
> Karen
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Tasks - layout
Posted by Karen Lease <kl...@club-internet.fr>.
Hi Tony,
Thanks for the advice. I have already started to look at the OpenType
standard, in particular the parts describing the various baselines.
Unfortunately I don't suppose I'll be attending the Unicode conference
but perhaps someone here will be and could listen to Steve's talk and
could report back to the group.
However, it seems clear that FOP will definitely need to enhance the
information it is managing about Fonts in order to provide the baseline
information needed to implement these aspects of the spec.
Regards,
Karen
Tony Graham wrote:
> Karen Lease wrote at 20 Aug 2002 23:07:46 +0200:
> > That would be good. I haven't looked at it for a month or so, but I had
> > (as usual) some questions about various statements in the XSL-FO spec
> > concerning the interpretation of the various properties. Perhaps we
> > could go over those issues at some point.
> ....
> > Arved Sandstrom wrote:
> >
> > >>-----Original Message-----
> > >>From: Karen Lease [mailto:klease@club-internet.fr]
> ....
> > >>With regard to the line-height calculations, is anybody in the group
> > >>interested in getting into the gory details of the baseline stuff for
> > >>different scripts? I spent some time poring over the spec and trying to
> > >>get a handle on this, but maybe it's too much detail for now. On the
> > >>other hand, I'd really like to make sure that this version of FOP
> > >>handles that stuff correctly as well as being able to do the various
> > >>kinds of line-stacking strategies defined by the XSL-FO spec.
> > >>
> > >
> > > I am definitely interested. I have put some thought into these things
> > > already. Granted, when I implement it'll be a different codebase but I am
> > > happy to work out the details on this list.
>
> You may be interested in Steve Zilles's statement in the abstract [1]
> for his talk at next month's Unicode Conference where he says:
>
> The extended CSS/XSL model is based on the Open Type font
> model. This model posits a set of alignment baselines for different
> scripts, e.g., alphabetic, ideographic and hanging scripts. This
> allows characters in a given script, but presented in different
> font sizes, to be aligned on the baseline natural to that script.
>
> I just looked in the XSL Recommendation, and Section 7.8.1 notes:
>
> XSL uses an abstract model of a font. This model is described in
> this section and is based on current font technology as exemplified
> by the OpenType specification [OpenType].
>
> Maybe you also need to look at the OpenType spec.
>
> Regards,
>
>
> Tony Graham
> ------------------------------------------------------------------------
> XML Technology Center - Dublin mailto:tony.graham@sun.com
> Sun Microsystems Ireland Ltd Phone: +353 1 8199708
> Hamilton House, East Point Business Park, Dublin 3 x(70)19708
>
>
> [1] http://www.unicode.org/iuc/iuc22/a365.html
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
> For additional commands, email: fop-dev-help@xml.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Tasks - layout
Posted by Tony Graham <To...@Sun.COM>.
Karen Lease wrote at 20 Aug 2002 23:07:46 +0200:
> That would be good. I haven't looked at it for a month or so, but I had
> (as usual) some questions about various statements in the XSL-FO spec
> concerning the interpretation of the various properties. Perhaps we
> could go over those issues at some point.
...
> Arved Sandstrom wrote:
>
> >>-----Original Message-----
> >>From: Karen Lease [mailto:klease@club-internet.fr]
...
> >>With regard to the line-height calculations, is anybody in the group
> >>interested in getting into the gory details of the baseline stuff for
> >>different scripts? I spent some time poring over the spec and trying to
> >>get a handle on this, but maybe it's too much detail for now. On the
> >>other hand, I'd really like to make sure that this version of FOP
> >>handles that stuff correctly as well as being able to do the various
> >>kinds of line-stacking strategies defined by the XSL-FO spec.
> >>
> >
> > I am definitely interested. I have put some thought into these things
> > already. Granted, when I implement it'll be a different codebase but I am
> > happy to work out the details on this list.
You may be interested in Steve Zilles's statement in the abstract [1]
for his talk at next month's Unicode Conference where he says:
The extended CSS/XSL model is based on the Open Type font
model. This model posits a set of alignment baselines for different
scripts, e.g., alphabetic, ideographic and hanging scripts. This
allows characters in a given script, but presented in different
font sizes, to be aligned on the baseline natural to that script.
I just looked in the XSL Recommendation, and Section 7.8.1 notes:
XSL uses an abstract model of a font. This model is described in
this section and is based on current font technology as exemplified
by the OpenType specification [OpenType].
Maybe you also need to look at the OpenType spec.
Regards,
Tony Graham
------------------------------------------------------------------------
XML Technology Center - Dublin mailto:tony.graham@sun.com
Sun Microsystems Ireland Ltd Phone: +353 1 8199708
Hamilton House, East Point Business Park, Dublin 3 x(70)19708
[1] http://www.unicode.org/iuc/iuc22/a365.html
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Tasks - layout
Posted by Karen Lease <kl...@club-internet.fr>.
Arved,
That would be good. I haven't looked at it for a month or so, but I had
(as usual) some questions about various statements in the XSL-FO spec
concerning the interpretation of the various properties. Perhaps we
could go over those issues at some point.
Karen
Arved Sandstrom wrote:
>>-----Original Message-----
>>From: Karen Lease [mailto:klease@club-internet.fr]
>>Sent: August 19, 2002 6:58 PM
>>To: fop-dev@xml.apache.org
>>Subject: Re: Tasks - layout
>>
>>
> [ SNIP ]
>
>>With regard to the line-height calculations, is anybody in the group
>>interested in getting into the gory details of the baseline stuff for
>>different scripts? I spent some time poring over the spec and trying to
>>get a handle on this, but maybe it's too much detail for now. On the
>>other hand, I'd really like to make sure that this version of FOP
>>handles that stuff correctly as well as being able to do the various
>>kinds of line-stacking strategies defined by the XSL-FO spec.
>>
>
> I am definitely interested. I have put some thought into these things
> already. Granted, when I implement it'll be a different codebase but I am
> happy to work out the details on this list.
>
> Arved
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
> For additional commands, email: fop-dev-help@xml.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
RE: Tasks - layout
Posted by Arved Sandstrom <Ar...@chebucto.ns.ca>.
> -----Original Message-----
> From: Karen Lease [mailto:klease@club-internet.fr]
> Sent: August 19, 2002 6:58 PM
> To: fop-dev@xml.apache.org
> Subject: Re: Tasks - layout
>
[ SNIP ]
> With regard to the line-height calculations, is anybody in the group
> interested in getting into the gory details of the baseline stuff for
> different scripts? I spent some time poring over the spec and trying to
> get a handle on this, but maybe it's too much detail for now. On the
> other hand, I'd really like to make sure that this version of FOP
> handles that stuff correctly as well as being able to do the various
> kinds of line-stacking strategies defined by the XSL-FO spec.
I am definitely interested. I have put some thought into these things
already. Granted, when I implement it'll be a different codebase but I am
happy to work out the details on this list.
Arved
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Tasks - layout
Posted by Karen Lease <kl...@club-internet.fr>.
Hi Keiron etc,
I'm really happy to see all this movement going on and folks from the
"maintenance" branch getting into the redesign to help you out. I'm
hoping to be able to start contributing again too, perhaps not right
away, but hopefully in September. There may even be some possibility of
getting to work on FOP as part of my "real" work, though it might be
hard to work on the new layout in that context. I'll keep the group posted.
I'll start by looking at the latest and then maybe cogitating on list or
table layout, depending on the timing and what others are interested in
doing. It looks like status.xml is the sign-up sheet for the tasks; is
that right?
With regard to the line-height calculations, is anybody in the group
interested in getting into the gory details of the baseline stuff for
different scripts? I spent some time poring over the spec and trying to
get a handle on this, but maybe it's too much detail for now. On the
other hand, I'd really like to make sure that this version of FOP
handles that stuff correctly as well as being able to do the various
kinds of line-stacking strategies defined by the XSL-FO spec.
Regards,
Karen
Keiron Liddle wrote:
> Now that we have some pagination there are lots of areas that people can
> work on.
> If you want to implement any of these and have any questions then just
> ask.
>
> Once we can get a few of these done then we could do a developers
> release.
>
>
> - Add static areas to page
> The static areas will need to be handled in a similar way to the flow
> except the bpd is unlimited and it will need to reset and repeat for
> each page.
>
>
> - Add id areas to page when area added
> When the layout managers add an area to the page it can also add the id
> information.
>
>
> - Resolve id references on other pages, extensions
> When an id is added to a page this will allow id references to be
> resolved.
>
>
> - Add markers to page when areas added
> When an area is added that is created by an FO that contains markers
> then the markers can also be added. There are four types of positions
> for markers.
>
>
> - Retrieve markers from page
> When doing the static areas the markers wil need to be available for
> retrieving. The marker can then be layed out as normal.
>
>
> - calculate line height
> The line height needs to be calculated while finding breaks. This needs
> to include all the alignment and height details of the inline areas.
>
>
> - Various inline objects
> Page number, page number citation etc. need to be implemented.
>
>
> - Implement page caching
> If a page need to be stored for the store pages or waiting to resolve
> forward references then we need a cache mechanism to save the page
> somewhere.
>
>
> - Implement table layout
> The table layout will use the same technique as the block layout. It
> will locate suitable breaks between rows or inside rows until table
> finished or end of bpd reached.
>
>
> - Implement list layout
> The list layout like the table layout will be looking for suitable
> breaks from the child objects. The it will add the appropriate areas to
> the area tree.
>
>
> - Get bookmark extension working
> Make sure the extension id references are resolved. Once the data is
> fully resolved then implement a way for the pdf renderer to add the
> bookmarks. See branch for code how to add bookmarks.
>
>
> These are just some of the things, I will add them to the todo list.
> If there is a decent response then there are more that can be added.
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
> For additional commands, email: fop-dev-help@xml.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Tasks - layout
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Kevin O'Neill wrote:
> Any PDF tasks?
>
Encryption related stuff seems to be often asked for.
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Tasks - layout
Posted by Keiron Liddle <ke...@aftexsw.com>.
On Wed, 2002-08-14 at 08:32, Kevin O'Neill wrote:
> > - Reusing pdf objects that links create
>
> What do you mean ... sorry for being dim.
The same as I did for the GState and patterns. If a link is added that
has the same action or destination URL as a previous link. Then use the
pdf objects with the actions etc. again. So for example if a document
has 100 links that point to the same URL then it will only create one
URL destination object instead of 100 (or whatever objects it creates I
don't have the code in front of me right now).
This could be done along the lines of:
- create an equals method in the objects that will be reused.
- when adding a new link then check if the pdf object already exists and
use the old one instead.
> > - form XObject
>
> Already started, I need it for some imposition code I'm working on
> (unless someone can think of a better way to do impositioning of pages).
Great!
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Tasks - layout
Posted by Kevin O'Neill <ke...@rocketred.com.au>.
On Wed, 2002-08-14 at 16:16, Keiron Liddle wrote:
> - Encryption and signing
Started looking at it (though I'm not using it at the moment and I'm a
little driven by the things I need :)).
> - Reusing pdf objects that links create
What do you mean ... sorry for being dim.
> - form XObject
Already started, I need it for some imposition code I'm working on
(unless someone can think of a better way to do impositioning of pages).
> Those are the main ones I can think of.
--
If you don't test then your code is only a collection of bugs which
apparently behave like a working program.
Website: http://radio.weblogs.com/0111457/
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Tasks - layout
Posted by Keiron Liddle <ke...@aftexsw.com>.
On Mon, 2002-08-12 at 13:44, Kevin O'Neill wrote:
> > These are just some of the things, I will add them to the todo list.
> > If there is a decent response then there are more that can be added.
>
> Any PDF tasks?
- Encryption and signing
- Reusing pdf objects that links create
- form XObject
Those are the main ones I can think of.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Tasks - layout
Posted by Kevin O'Neill <ke...@rocketred.com.au>.
> These are just some of the things, I will add them to the todo list.
> If there is a decent response then there are more that can be added.
Any PDF tasks?
--
If you don't test then your code is only a collection of bugs which
apparently behave like a working program.
Website: http://radio.weblogs.com/0111457/
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Tasks - layout
Posted by Keiron Liddle <ke...@aftexsw.com>.
On Mon, 2002-08-19 at 23:13, J.Pietschmann wrote:
> Keiron Liddle wrote:
> > - Implement table layout
> > The table layout will use the same technique as the block layout. It
> > will locate suitable breaks between rows or inside rows until table
> > finished or end of bpd reached.
>
> Actually, what *are* valid breaks within a table apart from breaks
> between two rows with no cell spanning both?
>
> Some interesting situations:
>
> +-----------------+--------------------+
> |block |block 1 |
> | |block 2 |
> +-----------------+--------------------+
> Break possibility after block 1 if
> BPD(block)<BPD(block 1), i.e.
> +-----------------+--------------------+
> |block |block 1 |
> +-----------------+--------------------+
> -------------------------------------------
> +-----------------+--------------------+
> | |block 2 |
> +-----------------+--------------------+
For this case I would say it is a valid break. Because table row can
have keep together which only makes sense if the row can be split when
there is no keep.
> +-----------------+--------------------+
> |block block block|block 1 |
> |block block block+--------------------+
> |block block |block 2 |
> +-----------------+--------------------+
> Break possibility after row one, despite that
> the cell with block 1 would have to get some
> space after the block, i.e.
> +-----------------+--------------------+
> |block block block|block 1 |
> |block block block| |
> |block block +--------------------+
> -------------------------------------------
> | +--------------------+
> | |block 2 |
> +-----------------+--------------------+
It should be possible to get a break inside a cell but I don't know how
the break should be found across the row.
What happens if there is a page-break inside a cell. Do other cells go
to the end of the page or to their limit? or should the break be at the
same position across the row.
Keiron.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Tasks - layout
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Keiron Liddle wrote:
> - Implement table layout
> The table layout will use the same technique as the block layout. It
> will locate suitable breaks between rows or inside rows until table
> finished or end of bpd reached.
Actually, what *are* valid breaks within a table apart from breaks
between two rows with no cell spanning both?
Some interesting situations:
+-----------------+--------------------+
|block |block 1 |
| |block 2 |
+-----------------+--------------------+
Break possibility after block 1 if
BPD(block)<BPD(block 1), i.e.
+-----------------+--------------------+
|block |block 1 |
+-----------------+--------------------+
-------------------------------------------
+-----------------+--------------------+
| |block 2 |
+-----------------+--------------------+
+-----------------+--------------------+
|block block block|block 1 |
|block block block+--------------------+
|block block |block 2 |
+-----------------+--------------------+
Break possibility after row one, despite that
the cell with block 1 would have to get some
space after the block, i.e.
+-----------------+--------------------+
|block block block|block 1 |
|block block block| |
|block block +--------------------+
-------------------------------------------
| +--------------------+
| |block 2 |
+-----------------+--------------------+
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Tasks - layout
Posted by Keiron Liddle <ke...@aftexsw.com>.
On Mon, 2002-08-19 at 22:58, J.Pietschmann wrote:
> Keiron Liddle wrote:
> > - Add markers to page when areas added
> Is this really a good idea? Markers may be referenced
> long after they have been defined, tying them to the
> Page object would require keeping the pages in memory
> (see 0.20.5cvs: forward page references are *required*
> to force keeping pages in memory so that markers can
> be retrieved with document scope).
I thought the markers only apply to the current page but I haven't
really looked into it. If it does apply to pagesequence/document then it
should be on the page viewport like the id references, so that the page
can be removed leaving relevent information for use later.
There may be other places to keep the markers but the area tree might be
easier to keep track of.
> I thought about adding a running number for the page
> sequence and for the page within it's page sequence
> as well as the necessary information to make retrieving
> markers within a page work properly to the marker itself
> and store them in an Array list, with the current page
> perhaps storing the array index of the first marker of
> this page to speed up some retrieval modes.
Page numbers would be good.
I think that you only need at most four markers of a particular class
per page, so if it is a dictionary type case it doesn't need all the
markers in the middle of the page with the same class.
> J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Tasks - layout
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Keiron Liddle wrote:
> - Add markers to page when areas added
Is this really a good idea? Markers may be referenced
long after they have been defined, tying them to the
Page object would require keeping the pages in memory
(see 0.20.5cvs: forward page references are *required*
to force keeping pages in memory so that markers can
be retrieved with document scope).
I thought about adding a running number for the page
sequence and for the page within it's page sequence
as well as the necessary information to make retrieving
markers within a page work properly to the marker itself
and store them in an Array list, with the current page
perhaps storing the array index of the first marker of
this page to speed up some retrieval modes.
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
AW: Tasks - layout
Posted by Keiron Liddle <ke...@aftexsw.com>.
On Mon, 2002-08-12 at 21:17, J.U. Anderegg wrote:
> o Are there specified packages, classes to be programmed? Are the
> interfaces/interface objects specified?
Mostly yes, and if someone wants more information I can go into more
detail.
> o Are prerequisite packages or test drivers available?
I'mn not sure what you mean.
> o Are the basic formatting rules documented: how are (collapsing) borders,
> margins, spaces added and adjusted in area calculations,passed to renderers?
When someone works that out they can tell us.
> > As far as I know there is never a case where a finished page should be
> > redone. Once a page is complete that is it.
> > Those problems should be solved during the layout of a page only and not
> > considering furture pages.
>
> and if you have a TOC at the begin of a document, "see page 967" on page 3
> ("967" unresolved at formatting time of page 3)? Are optimal/maximal/minimal
> space, floats, footnotes, keeps, table breaks adequately handled without
> lookahead and backtracking, multiple formatting passes?
Even if you do multiple passes it is possible to never be able to fix
the layout.
The solution is to reserve some space for the "967" and when the value
is resolved then redo the layout for that line only. 99% of the time
this will work perfectly well.
> Hansuli Anderegg
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
AW: Tasks - layout
Posted by "J.U. Anderegg" <ha...@bluewin.ch>.
o Are there specified packages, classes to be programmed? Are the
interfaces/interface objects specified?
o Are prerequisite packages or test drivers available?
o Are the basic formatting rules documented: how are (collapsing) borders,
margins, spaces added and adjusted in area calculations,passed to renderers?
> As far as I know there is never a case where a finished page should be
> redone. Once a page is complete that is it.
> Those problems should be solved during the layout of a page only and not
> considering furture pages.
and if you have a TOC at the begin of a document, "see page 967" on page 3
("967" unresolved at formatting time of page 3)? Are optimal/maximal/minimal
space, floats, footnotes, keeps, table breaks adequately handled without
lookahead and backtracking, multiple formatting passes?
Hansuli Anderegg
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org