--- "J.Pietschmann" <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > Hyphenation problem in Bug 23985
>
> Actually, implementing UTR14 would solve the line
> breaking problem,
> although not the URL breaking problem.
>
Make sure you're separating the issues here...the bug
in question
Glen Mazza wrote:
Also, just to make sure I understand clearly--when you
say "force" I think you're referring to
"conditionality" (retain/discard),
Yes.
IIRC, by default, space-after is discarded if it would
be placed at the end of a reference area (something not
properly done in 0.20.5).
Thanks fo
I don't think I wrote that clearly--our current
implementation in BLM:
(1) in addAreas(), adds empty blocks to represent
space-before & space-after in one method, and
(2) in getNextBreakPoss(), reduces the "stackSize"
(BPD or "vertical" allowable writing area) to
compensate for (1) above when g
[EMAIL PROTECTED] wrote:
Hyphenation problem in Bug 23985
Actually, implementing UTR14 would solve the line breaking problem,
although not the URL breaking problem.
Points to discuss:
- JDK 1.4 has a java.text.BreakIterator, which implements UTR14, or
at least the parts releant for western langu
[EMAIL PROTECTED] wrote:
2.) The space-after of a block ending at the bottom of the page is not
currently being added to the beginning of the subsequent page.
It shouldn't unless it is explicitely forced.
J.Pietschmann
Peter B. West wrote:
Recall that the contents of fo:block are defined as
(#PCDATA|%inline;|%block;)*
and that there are some interesting complications in the contents of
"&inline;" which, frankly, I still don't understand in spite of
clarifications from the editors.
One complication is whitespa
> -Original Message-
> From: Siarhei Baidun [mailto:[EMAIL PROTECTED]
> 2. There is another branch of fop development, named "main". I took CVS
> snapshot of code from this branch. It is seemed that new fop
> works much more
> faster and vastly saves memory. In particular, for a lot of
> s
Thanks a lot for your answer
Hope it'll help
As far as usage of fop 0.20.5 is concerned , there are two main significant
reasons.
1. We have made a lot of amendments in version 0.20.4 that are specific for
our project
Merging our code with version 0.20.5 of fop will take a lot of time and we
have
From: "Siarhei Baidun" <[EMAIL PROTECTED]>
But fop of version 0.20.5 runs perfectly on the same data.
I can't use version 0.20.5 of fop because of number of reasons.
Please explain the specific reasons why you cant use 0.20.5. We may be able
to help you resolve these issues.
What I want to do
As I read it, no more than normal. If a block contains text, the
individual glyph areas will, conceptually, be assembled into line-areas.
There is no FO corresponding to a line-area. Where side-floats are
introduced, intrusion adjustment occurs, which may affect the placement
of text in line
Possibly (I haven't studied fo:float at this
time)--but we were speaking about a very specific
case, there may be many others that cause fo:blocks to
be split into multiple areas.
--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:
> Not that I'm a specialist in this area, but won't
> fo:float also cau
gmazza 2003/11/11 05:50:00
Modified:src/java/org/apache/fop/layoutmgr BlockLayoutManager.java
Log:
Partial implementation of space-after functionality--mostly working, but
some remaining problems:
1.) relying on a static variable to carry space-after value from previous
blo
Hi all
I have the following problem with fop.
I'm using fop of version 0.20.4rc. On several XML files fop runs extremely
slowly or falls down with OutOfMemoryError (though I set up
options -Xms64M -Xmx256M for JVM to increase memory at runtime).
But fop of version 0.20.5 runs perfectly on the sam
Not that I'm a specialist in this area, but won't fo:float also cause an
fo:block to be split into multiple areas even if the block itself
doesn't span multiple pages?
On 11.11.2003 01:30:18 Peter B. West wrote:
> I've always assumed that the one or more areas are a logical consequence
> of the f
From: Glen Mazza <[EMAIL PROTECTED]>
Yes, that it what I did. Thanks for your
suggestion--space-before seems to work well now.
Great-one step closer to a working layout in head.
Chris
_
Express yourself with cool emoticons - downlo
From: "J.Pietschmann" <[EMAIL PROTECTED]>
Chris Bowditch wrote:
I'm not sure where Layout Contexts should be instantiated. Any thoughts?
The are created in the getNextBreak stuff.
Yes they are created in getNextBreak and passed down to getNextBreak of
child LMs, but they are not passed to the cal
16 matches
Mail list logo
