fo:inline bpd

[Manuel Mall]

Currently fop sets the bpd of areas created from fo:inlines to to 
line-height of the line the area appears in.

For example:

Some text smaller 
text

The inline parent area created for the fo:inline will be given a bpd of 
12pt, i.e. the line-height of the surrounding block, and not 9.6pt 
which is the height of the fo:inline. 

The difference is visually noticeable to moment one applies backgrounds 
or borders/padding to the fo:inline.

Am I correct in saying that the current implementation is incorrect and 
that the smaller bpd should be applied in the example above?

Manuel

Line LM, Inline LM and LAST_AREA

[Manuel Mall]

I am trying to understand the logic related to determining if something 
is the "last area" generated for a LM, in this case for an Inline LM. 
If I understand it correctly the Line LM sets the LAST_AREA flag in the 
context when it generates the last area for a line. The Inline LM then 
checks if the LAST_AREA flag is set and if itself deals with its last 
child LM to determine if this is the last area for it. But if we have a 
long fo:inline stretching multiple lines this seem to give the wrong 
results from the Inline LM perspective. For example if the fo:inline 
finishes in the middle of a line followed by more text the Line LM will 
not set the LAST_AREA flag when calling addAreas on the Inline LM as 
there are more areas on the line. Therefore the Inline LM "thinks" its 
not done with yet although it is and the reverse is true on the first 
line of a multi-line inline.

Overall I am confused and wonder if whoever wrote this (or someone who 
understands this area of the code) can shed some light on it for me 
please.

In short, I need to know when the last area for a fo:inline is created 
and I am not clear at all how to do this.

Thanks

Manuel

RE: Logging for FOrayFont

[Victor Mote]

J.Pietschmann wrote:

> If you've looked into a fair number of open source projects, 
> and add projects from your work environment, you'll probably 
> see certain abstractions over and over again.
> Counting the number of reincarnations, logging certainly 
> comes into the top ten, I guess even at position three after 
> configuration services and i18n. The tendency to have a 
> project specific abstraction, however small, isn't new, check 
> out the history part in the syslogd docs.
> 
> If you are interested in a list of other recurring themes 
> beside the three named above:
> - service discovery, often including loading code or data
>   from a directory or some other repository
> - URL resolving
> - URI, URL, pathname and search path handling as Strings
> - command line argument parsing, maybe as part or complement
>   of a configuration service
> - object pooling, in particular network connection pooling
>   and multiplexing
> - XML creation
> - Java object persistence
> The list isn't complete of course.

OK. Still I miss your point. It could be any one of the following:
1. You are arguing against the "no external dependencies" idea.
2. You support the "no external dependencies" idea, and find it humorous
when someone has to reinvent the wheel to comply with it.
3. You support the "no external dependencies" idea, and think that there was
some more elegant solution that FOray should have implemented.
4. You agree with Jeremias that there is no need for logging information to
pass through an interface between two subsystems.
5. You agree that logging for such a system is not necessary.

The list isn't complete of course.

Victor Mote

Classpath setup problem

[J.Pietschmann]

Hi devs,
I just upgraded to Ant 1.6.5 and the junit tasks stopped
working (see Ant FAQ faq.html#delegating-classloader). I
really liked my setup where all jars were in a single
directory. :-(
It's too late in the evening for advanced reshuffling
of important libraries. What's your setup?

J.Pietschmann

Re: Logging for FOrayFont

[J.Pietschmann]

Victor Mote wrote:

Your meaning here is, at best, ambiguous. Please clarify.


If you've looked into a fair number of open source projects,
and add projects from your work environment, you'll probably
see certain abstractions over and over again.
Counting the number of reincarnations, logging certainly comes
into the top ten, I guess even at position three after
configuration services and i18n. The tendency to have a
project specific abstraction, however small, isn't new,
check out the history part in the syslogd docs.

If you are interested in a list of other recurring themes
beside the three named above:
- service discovery, often including loading code or data
 from a directory or some other repository
- URL resolving
- URI, URL, pathname and search path handling as Strings
- command line argument parsing, maybe as part or complement
 of a configuration service
- object pooling, in particular network connection pooling
 and multiplexing
- XML creation
- Java object persistence
The list isn't complete of course.

J.Pietschmann

RE: Relative font weights and font selection

[Victor Mote]

Victor Mote wrote (August 27, 2005):

> > > In order to move forward, I suggest the addition of the following 
> > > methods in
> > > org.axsl.font.Font:
> > > 
> > > public byte nextBolderWeight();
> > > public byte nextLighterWeight();
> > > public org.axsl.font.Font nextBolderFont();
> > > public org.axsl.font.Font nextLighterFont();

...

> > > There is another area complexity in font selection that 
> has not yet 
> > > been addressed, so I pose it here to Vincent and Manuel 
> especially, 
> > > and to any others who wish to comment. The whole issue of
> > whether the
> > > Font has a glyph for the character(s) has not yet been
> > addressed. The
> > > best idea I have for this is as follows:
> > > 
> > > 1. Add a char to the signature of
> > org.axsl.font.FontServer.selectFont. 
> > > This char represents the first char of the text for which
> > the font is
> > > being selected. This allows the selection process to pass by a 
> > > font-family if it cannot paint the character.

...

> > > 2. Add the following method to org.axsl.font.Font:
> > > /**
> > >  * Examines each character in string to ensure that a
> > glyph exists
> > > in the font for that
> > >  * character. If a character has no glyph in the font, the 
> > > character's index in string
> > >  * is returned.
> > >  * @return The index in string of its first character
> > for which no
> > > glyph exists in this
> > >  * font. If all characters in the string have glyphs in
> > this font,
> > > -1 is returned.
> > >  */
> > > public int unavailableChar(String string);
> > > 
> > > Add also an overridden version of this method with
> > char[] as the
> > > parameter.
> > 
> > Why not directly return an array of all indexes where there is a 
> > missing glyph?
> 
> OK. Probably in a separate method called unavailableChars.
> 
> > Or add a beginIndex parameter so that one doesn't have to 
> artificially 
> > recreate a String made of the initial String minus all 
> characters up 
> > to the first missing glyph?
> 
> Yes. That definitely needs to be there.

The following methods have now been added to org.axsl.font.Font:
public byte nextBolderWeight() ;
public byte nextLighterWeight() ;
public Font nextBolderFont() ;
public Font nextLighterFont() ;

public int unavailableChar(String string, int beginIndex) ;
public int unavailableChar(char[] chars, int beginIndex) ;
public int[] unavailableChars(String string, int beginIndex) ;
public int[] unavailableChars(char[] chars, int beginIndex) ;

and a char has been added to the signature of the method
org.axsl.font.FontServer.selectFont.

Stub implementations have been created in FOray, but the added functionality
is, in general, not actually in place yet. I'll get to that as I am able,
but at least those working with the interface can move forward when they are
ready.

Victor Mote

Re: Logging for FOrayFont

[Jeremias Maerki]

I'm sorry but I've got to stop here. No energy left for this discussion.
I didn't manage to get my meaning across and so we're talking about
different things. I'll try to look into aXSL and FOray later and see if
I can create a patch to demonstrate what I was talking about. Sorry for
wasting your time. This was really not directed at you but rather at the
FOP team so they know we have a potential problem when moving code over
to Commons. It wasn't supposed to extend into such a discussion. I'm
anxious to see what happens when I actually start to migrate code to
Commons

On 05.09.2005 22:29:46 Victor Mote wrote:
> Jeremias Maerki wrote:
> 
> > > A PseudoLogger is required (but can be passed
> > > null) in the FontServer constructor
> > 
> > That's an implementation detail and not a problem. It has 
> > nothing to do with the API. FontServer is an interface in the 
> > API and you are talking about the implementation of 
> > FontServer here, I assume.
> 
> Well, it may have nothing to do with the aXSL API, but it certainly has
> something to do with the FOray API. To implement FOray (which I understand
> to be the discussion), you have to do both. If it is wrong to demand a
> logging mechanism in aXSL's API, how can it then be right to do so in
> FOray's API? It sounds like I could solve all of your concerns by creating a
> FOray FontConsumer implementation that is an abstract class, making you pick
> some class to extend it, and then simply demanding a logging mechanism in
> the implementation's constructor.
> 
> Am I right? If so, doesn't it all seem silly? The client application now has
> to have implementation-specific code embedded at FontConsumer (document)
> construction. Poof. Pluggability just disappeared. For what benefit? None.
> Your client application still supplies exactly the same thing it supplied
> the other way.
> 
> Really, why does FOP care whether it needs to supply logging information
> because aXSL requires it or because FOray requires it?
> 
> > > and is required in a method in
> > > FontConsumer. But FontConsumer is implemented on the client 
> > side, in 
> > > which the client application tells FOray about itself.
> > 
> > This method getPseudoLogger() is what caught my purist's eye 
> > in the first place. It breaks IoC.
> 
> I don't care. (I am sure that comes across more rudely than I intend). There
> are more important things here.
>
> > > Second, why should FOray limit its clients to only use 
> > static logging? 
> > > If the client has to expose a static logging mechanism to FOray in 
> > > order to get static logging to work, what can possibly be 
> > wrong with 
> > > exposing a non-static logging mechanism to FOray? Right now, FOray 
> > > doesn't care whether static or non-static logging is used. 
> > Why should it?
> > 
> > Exactly. Why should it? If you remove all logging concerns 
> > from the work interface you don't do any assumptions about 
> > how logging is done. The presence of getPseudoLogger(), 
> > though, produces a strong emphasis on non-static logging.
> 
> Not true. Your PseudoLogger implementation can use whatever logging it wants
> to, or, as may please you better, send it to /dev/null.
> 
> Again, if you accept implementation constructors as part of the API that FOP
> must deal with, then I think your whole line of reasoning disappears here.
> 
> > > Third, lets define the "concern". My understanding of 
> > > Separation of Concerns in this case is that FOrayFont owns 
> > the concern 
> > > that a message needs to be logged, and that the client application 
> > > owns the concern of how that logging should be 
> > > accomplished.
> > > 
> > > In order to maintain that Separation of Concerns, one of two things 
> > > must
> > > happen:
> > > 1. The client must tell the component how stuff should be logged.
> > > 2. The server must tell the client what should be logged.
> > > 
> > > This means some logging-related stuff will appear in the interface 
> > > between the two.
> > 
> > Not IMO. It can be an implementation detail. See more below.
> > 
> > > The design considerations are as follows:
> > > 1. FOrayFont needs to be able to log messages.
> > 
> > For whom? For the developer or for the end-user? Because 
> 
> Ah, now this is what I consider to be an implementation detail!
> 
> > that's what I've learned during the past months: That it 
> > should be well divided between the two audiences. The 
> > speciality is that the developer doesn't need a logger per 
> > processing run (i.e. non-static logging) and the end-user 
> > often needs more than just pure Strings through a generic 
> > logging interface. Note that this is not yet reality in FOP 
> > but I believe it will be soon.
> 
> Well, I noticed that you chose to ignore the  tag, and it shows
> up here. Why should the component concern itself with the differences
> between the two audiences? If a user wants to log debug or trace messages
> into a permanent file somewhere, what business is t

Re: [VOTE] Manuel Mall as new FOP committer

[The Web Maestro]

+1 from me also!

On Sep 5, 2005, at 1:29 AM, Jeremias Maerki wrote:

Manuel Mall has been investing a tremendous amount of time and effort
into making FOP better lately. The results were just great. It's been a
pleasure to apply his patches, even though it ate up a lot of my time.
;-) Manuel has been around since at least late 2002, even submitted a
patch back then. He shows a good understanding of how things work in 
our

project and is quick to learn in other areas. He doesn't fear diving
into the code of the layout engine. That's exactly the sort of people 
we

need in the project team. That's why I'd like to nominate him for
committership in Apache FOP.

Jeremias Maerki


Regards,

Web Maestro Clay
--
<[EMAIL PROTECTED]> - 
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

Re: Build error

[Jeremias Maerki]

Weird, why does it want Service? I've added SubInputStream and all runs
through.

On 05.09.2005 22:17:41 Simon Pepping wrote:
> On Mon, Sep 05, 2005 at 09:21:09PM +0200, Jeremias Maerki wrote:
> > You can't, I can. My fault, sorry.
> > http://svn.apache.org/viewcvs?rev=278816&view=rev
> 
> Thanks, that works. Another error, in junit:
> 
> [junit] Testcase: 
> testGenericPDFTranscoder(org.apache.fop.BasicPSTranscoderTestCase): 
> Caused an ERROR
> [junit] org/apache/fop/util/SubInputStream
> [junit] java.lang.NoClassDefFoundError: org/apache/fop/util/SubInputStream
> 
> Indeed, fop-transcoder.jar and fop-transcoder-allinone.jar do not
> contain Service and SubInputStream in the util package.
> 
> Simon
> 
> -- 
> Simon Pepping
> home page: http://www.leverkruid.nl



Jeremias Maerki

RE: Logging for FOrayFont

[Victor Mote]

J.Pietschmann wrote:

> > /me ducks.
> 
> Hehe. I've also thought again that designing certain 
> interfaces (and piling them on each other) must be really really fun.

Your meaning here is, at best, ambiguous. Please clarify.

Victor Mote

RE: Logging for FOrayFont

[Victor Mote]

Jeremias Maerki wrote:

> > A PseudoLogger is required (but can be passed
> > null) in the FontServer constructor
> 
> That's an implementation detail and not a problem. It has 
> nothing to do with the API. FontServer is an interface in the 
> API and you are talking about the implementation of 
> FontServer here, I assume.

Well, it may have nothing to do with the aXSL API, but it certainly has
something to do with the FOray API. To implement FOray (which I understand
to be the discussion), you have to do both. If it is wrong to demand a
logging mechanism in aXSL's API, how can it then be right to do so in
FOray's API? It sounds like I could solve all of your concerns by creating a
FOray FontConsumer implementation that is an abstract class, making you pick
some class to extend it, and then simply demanding a logging mechanism in
the implementation's constructor.

Am I right? If so, doesn't it all seem silly? The client application now has
to have implementation-specific code embedded at FontConsumer (document)
construction. Poof. Pluggability just disappeared. For what benefit? None.
Your client application still supplies exactly the same thing it supplied
the other way.

Really, why does FOP care whether it needs to supply logging information
because aXSL requires it or because FOray requires it?

> > and is required in a method in
> > FontConsumer. But FontConsumer is implemented on the client 
> side, in 
> > which the client application tells FOray about itself.
> 
> This method getPseudoLogger() is what caught my purist's eye 
> in the first place. It breaks IoC.

I don't care. (I am sure that comes across more rudely than I intend). There
are more important things here.

> > Second, why should FOray limit its clients to only use 
> static logging? 
> > If the client has to expose a static logging mechanism to FOray in 
> > order to get static logging to work, what can possibly be 
> wrong with 
> > exposing a non-static logging mechanism to FOray? Right now, FOray 
> > doesn't care whether static or non-static logging is used. 
> Why should it?
> 
> Exactly. Why should it? If you remove all logging concerns 
> from the work interface you don't do any assumptions about 
> how logging is done. The presence of getPseudoLogger(), 
> though, produces a strong emphasis on non-static logging.

Not true. Your PseudoLogger implementation can use whatever logging it wants
to, or, as may please you better, send it to /dev/null.

Again, if you accept implementation constructors as part of the API that FOP
must deal with, then I think your whole line of reasoning disappears here.

> > Third, lets define the "concern". My understanding of 
> > Separation of Concerns in this case is that FOrayFont owns 
> the concern 
> > that a message needs to be logged, and that the client application 
> > owns the concern of how that logging should be 
> > accomplished.
> > 
> > In order to maintain that Separation of Concerns, one of two things 
> > must
> > happen:
> > 1. The client must tell the component how stuff should be logged.
> > 2. The server must tell the client what should be logged.
> > 
> > This means some logging-related stuff will appear in the interface 
> > between the two.
> 
> Not IMO. It can be an implementation detail. See more below.
> 
> > The design considerations are as follows:
> > 1. FOrayFont needs to be able to log messages.
> 
> For whom? For the developer or for the end-user? Because 

Ah, now this is what I consider to be an implementation detail!

> that's what I've learned during the past months: That it 
> should be well divided between the two audiences. The 
> speciality is that the developer doesn't need a logger per 
> processing run (i.e. non-static logging) and the end-user 
> often needs more than just pure Strings through a generic 
> logging interface. Note that this is not yet reality in FOP 
> but I believe it will be soon.

Well, I noticed that you chose to ignore the  tag, and it shows
up here. Why should the component concern itself with the differences
between the two audiences? If a user wants to log debug or trace messages
into a permanent file somewhere, what business is that of FOrayFont's
All it should do is respond to the level of detail that is requested by the
client application, and to place it where the client application wants, both
of which, AFAICT, you won't allow me to find out.

> > 2. FOrayFont needs to be able to work with any client system, 
> > regardless of their preferences on logging.
> 
> Nobody challenges that. Due to input from Batik the question 
> is raised whether such a library should do any logging at 
> all. Don't get me wrong.

If you don't want to do any logging, send the log messages to /dev/null. But
it is not reasonable to insist that other client applications must
effectively do the same thing by never getting the opportunity to log.

> I'm all for developer-oriented logging, even in basic 
> libraries. It's just that I somehow need 

Re: Build error

[Simon Pepping]

On Mon, Sep 05, 2005 at 09:21:09PM +0200, Jeremias Maerki wrote:
> You can't, I can. My fault, sorry.
> http://svn.apache.org/viewcvs?rev=278816&view=rev

Thanks, that works. Another error, in junit:

[junit] Testcase: 
testGenericPDFTranscoder(org.apache.fop.BasicPSTranscoderTestCase):   
Caused an ERROR
[junit] org/apache/fop/util/SubInputStream
[junit] java.lang.NoClassDefFoundError: org/apache/fop/util/SubInputStream

Indeed, fop-transcoder.jar and fop-transcoder-allinone.jar do not
contain Service and SubInputStream in the util package.

Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl

Re: Logging for FOrayFont

[Jeremias Maerki]

As I said, widely differing views between Batik and FOP about this. In
my own personal opinion, I'm with you. From the POV of XML Graphics
Commons we have a problem. We've voted on the plan for Commons where we
said that we'd try to remove the dependency on Commons Logging. If there
is a problem with that, the right place to raise this is
[EMAIL PROTECTED]

On 05.09.2005 21:15:50 Simon Pepping wrote:

> I am not sure that I understand everything that is being said
> here. But I am alarmed when I hear that basic libraries, in this case
> the FontServer, shouldn't log anymore. In my experience a font system
> requires powerful logging, in order to expose runtime behaviour to the
> systems manager or end user. Configuring font systems and
> understanding why a piece of font software does not use it as you
> expect, is a hard task that requires suitable runtime information from
> the software.

Jeremias Maerki

Re: Logging for FOrayFont

[J.Pietschmann]

Jeremias Maerki wrote:

I'm ever growing more cofident that
developer-oriented logging should be done through a static logging
facility (like Commons Logging) and that end-user-oriented logging needs
to operate per processing run (like Avalon Logger) but not necessarily
through a standard logging abstraction interface, but rather an
application-specific one that provides exactly what the application
needs to send feedback to the end-users. 


That's a major part of the points at the end of
http://mail-archives.apache.org/mod_mbox/xmlgraphics-fop-dev/200508.mbox/[EMAIL 
PROTECTED]

The idea is that FOP sends certain events (or messages) to the User
Agent interface and let the app specific user agent implementation sort
out whether it wants to log it, throw an exception, show a message box,
whatever.
The static debug/trace mechanism is a welcomed refinement, I'd
thought of exposing the logger from the user agent to the rest
of the code for this purpose. It is quite possible that the event
signalling methods proposed in the post above need to be split
up further.


/me ducks.


Hehe. I've also thought again that designing certain interfaces
(and piling them on each other) must be really really fun.

J.Pietschmann

Re: Build error

[Jeremias Maerki]

You can't, I can. My fault, sorry.
http://svn.apache.org/viewcvs?rev=278816&view=rev

On 05.09.2005 21:02:16 Simon Pepping wrote:
> Hi,
> 
> I get a build error:
> 
> [javac] Compiling 653 source files to 
> /fsb/fsc/source/xml-fop/build/classes
> [javac] 
> /fsb/fsc/source/xml-fop/src/java/org/apache/fop/render/ps/PSFontUtils.java:166:
>  cannot resolve symbol
> [javac] symbol  : method copy 
> (org.apache.fop.util.SubInputStream,org.apache.fop.util.ASCIIHexOutputStream)
> [javac] location: class org.apache.commons.io.IOUtils
> [javac] IOUtils.copy(sin, hexOut);
> [javac]^
> [javac] 1 error
> 
> BUILD FAILED
> 
> How can I solve this?



Jeremias Maerki

Re: [VOTE] Manuel Mall as new FOP committer

[Simon Pepping]

+1 from me.

Regards, Simon

On Mon, Sep 05, 2005 at 10:29:36AM +0200, Jeremias Maerki wrote:
> Manuel Mall has been investing a tremendous amount of time and effort
> into making FOP better lately. The results were just great. It's been a
> pleasure to apply his patches, even though it ate up a lot of my time.
> ;-) Manuel has been around since at least late 2002, even submitted a
> patch back then. He shows a good understanding of how things work in our
> project and is quick to learn in other areas. He doesn't fear diving
> into the code of the layout engine. That's exactly the sort of people we
> need in the project team. That's why I'd like to nominate him for
> committership in Apache FOP.
> 
> Jeremias Maerki
> 

-- 
Simon Pepping
home page: http://www.leverkruid.nl

Re: Logging for FOrayFont

[Simon Pepping]

On Mon, Sep 05, 2005 at 07:33:33PM +0200, Jeremias Maerki wrote:
> 
> On 05.09.2005 17:05:48 Victor Mote wrote:
> > Jeremias Maerki wrote:
> > 
> > The design considerations are as follows:
> > 1. FOrayFont needs to be able to log messages.
> 
> For whom? For the developer or for the end-user? Because that's what
> I've learned during the past months: That it should be well divided
> between the two audiences. The speciality is that the developer doesn't
> need a logger per processing run (i.e. non-static logging) and the
> end-user often needs more than just pure Strings through a generic
> logging interface. Note that this is not yet reality in FOP but I
> believe it will be soon.
> 

> > > Now, I know this has the potential to spark a heated debate 
> > > again and it raises question marks about the FOrayFont 
> > > integration, but ATM I really don't know what to do about it 
> > > right now. I just realized we have a problem here. I/we made 
> > > promises on general@xmlgraphics.apache.org to try to remove 
> > > logging and other external dependencies (like Avalon) for the 
> > > common components because that's something which is very 
> > > important to the Batik side.
> > 
> > So, then, how are those components supposed to log anything? Or, if they are
> > to log using their own static stuff, how can this be configured by the
> > client?
> 
> Eventually such basic libraries shouldn't log anything anymore. That's
> the big dilemma I'm sitting in, the one I need to find a way out of.
> Anyway, ways to remove the necessity to log are: unit tests and
> stabilization. The problem is getting rid of something so extremely
> handy but actually completely unnecessary for something basic like a PDF
> or font library. But I'd never want to get rid of the ability to log in
> a complex system like a layout engine.

I am not sure that I understand everything that is being said
here. But I am alarmed when I hear that basic libraries, in this case
the FontServer, shouldn't log anymore. In my experience a font system
requires powerful logging, in order to expose runtime behaviour to the
systems manager or end user. Configuring font systems and
understanding why a piece of font software does not use it as you
expect, is a hard task that requires suitable runtime information from
the software.

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl

Build error

[Simon Pepping]

Hi,

I get a build error:

[javac] Compiling 653 source files to /fsb/fsc/source/xml-fop/build/classes
[javac] 
/fsb/fsc/source/xml-fop/src/java/org/apache/fop/render/ps/PSFontUtils.java:166: 
cannot resolve symbol
[javac] symbol  : method copy 
(org.apache.fop.util.SubInputStream,org.apache.fop.util.ASCIIHexOutputStream)
[javac] location: class org.apache.commons.io.IOUtils
[javac] IOUtils.copy(sin, hexOut);
[javac]^
[javac] 1 error

BUILD FAILED

How can I solve this?

Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl

Re: [ANN] new aXSL interface for FO Tree

[Simon Pepping]

Victor,

I find this certainly interesting. IN principle, it would allow client
programs, say an editor, to construct its own implementation of the
FOTree interface.

Simon

On Sat, Sep 03, 2005 at 04:45:33PM -0600, Victor Mote wrote:
> FWIW, I completed today the extraction of a set of interfaces for aXSL to
> generically describe an FO Tree. The FOray FOTree implements these
> interfaces, and the other FOray modules have been changed to use the aXSL
> interfaces instead of the FOray FOTree implementation. The only dependency
> within FOray on FOray FOTree now is one that handles creating a default
> implementation if none is passed to FOraySession.
> 
> For some time now, the FOray FOTree has been available as an independent
> module. This new set of interfaces theoretically allow non-FOray FOTree
> implementations to be used within FOray. I realize that there is not a great
> demand for this ATM. However, there are numerous immediate benefits:
> 1. It is now possible to more clearly "show" rather than merely "tell" the
> "where" and "when" issues that I described in another thread earlier this
> week.
> 2. There is something about having to extract an interface that forces one
> to address ugly design issues and get them cleaned up. I found and fixed a
> few. There are probably still some others that will become apparent in a
> closer review of the interfaces.
> 3. It opens the door to the possibility of comparing different FO Tree
> implementations to each other with other components remaining fixed. I don't
> know whether the FOP FO Tree can be adapted to implement this interface or
> not, but I suspect that it can.
> 
> For any who are interested, the code can be conveniently viewed here:
> http://cvs.sourceforge.net/viewcvs.py/axsl/axsl/axsl-fotree/src/java/org/axs
> l/fotree/
> 
> The slightly bad news for Jeremias is that the outer-level FOray API has
> changed to accommodate the new FOTreeServer that allows this pluggability.
> However, this is easily fixed by passing one more "null" parameter in the
> FOraySession constructor.
> 
> The interfaces are not well documented ATM and are no doubt weak in many
> other ways as well. A great many of the interfaces are empty markers,
> providing type identification only. There may be a better way to handle
> this. Or it may turn out that additional methods will need to be added to
> them to accommodate more sophisticated needs.
> 
> I hope this is of general interest to this list, and apologize if it is not.
> 
> Victor Mote
> 

-- 
Simon Pepping
home page: http://www.leverkruid.nl

Re: Logging for FOrayFont

[Jeremias Maerki]

On 05.09.2005 17:05:48 Victor Mote wrote:
> Jeremias Maerki wrote:
> 
> > I got a little shock when I realized a problem I didn't think 
> > of when we discussed moving FOP components over to XML 
> > Graphics Commons. We said we would try to remove logging code 
> > from these basic components entirely.
> >
> > Now, I forgot to consider the decision to use FOrayFont made earlier.
> > The external dependency on FOrayFont also would be a problem 
> > in itself because the Batik side has strong feelings against 
> > external dependencies.
> > We need to think about what to do about this WRT the PDF and 
> > PS transcoders. Optimized text painting in these two 
> > transcoders depends a lot on the font subsystem.
> 
> Well, the little change I just made removes entirely any dependency on
> Avalon in any FOray code, except for the fact that Ant seems to need it for
> logging (needed for creating hyphenation patterns and such). There is no
> longer any Avalon code in FOrayFont. In fact, that was the primary
> motivation for making the change. The Avalon Logger interface would have
> been quite a sufficient solution for anything that FOray needs, and, since
> it is an interface, adapters could be written from it to anything else, just
> as Vincent and I have been discussing for the PseudoLogger interface.

Yeah, yet another generic logger abstraction interface. Sigh.

> > Aside from that, a thought about the aXSL APIs: Being an 
> > ex-Avaloner SoC (separation of concerns) is a big concern to 
> > me. The functional API of a package should IMO actually not 
> > deal with (or rather expose) logging at all. It's a separate 
> > concern. I'm ever growing more cofident that 
> > developer-oriented logging should be done through a static 
> > logging facility (like Commons Logging) and that 
> > end-user-oriented logging needs to operate per processing run 
> > (like Avalon Logger) but not necessarily through a standard 
> > logging abstraction interface, but rather an 
> > application-specific one that provides exactly what the 
> > application needs to send feedback to the end-users. In that 
> > light, a PDF or font library shouldn't expose any logging 
> > facilities at all or at least to static logging that is 
> > externally configured.
> 
> First, do you understand that the FOrayFont library does not "expose any
> logging facilities" to the client, but instead asks the client to expose the
> logging facilities to it?

Yes. Sorry for the not quite accurate wording plus a typo. Let's try
again: [a work interface] shouldn't expose any logging specifica (as
they are a separate concern, see Avalon's LogEnabled interface or newer
dependency injection systems). If developer-oriented logging is
absolutely necessary I prefer static logging (like Commons Logging or
Log4J) today.

> A PseudoLogger is required (but can be passed
> null) in the FontServer constructor

That's an implementation detail and not a problem. It has nothing to do
with the API. FontServer is an interface in the API and you are talking
about the implementation of FontServer here, I assume.

> and is required in a method in
> FontConsumer. But FontConsumer is implemented on the client side, in which
> the client application tells FOray about itself.

This method getPseudoLogger() is what caught my purist's eye in the
first place. It breaks IoC.

> Second, why should FOray limit its clients to only use static logging? If
> the client has to expose a static logging mechanism to FOray in order to get
> static logging to work, what can possibly be wrong with exposing a
> non-static logging mechanism to FOray? Right now, FOray doesn't care whether
> static or non-static logging is used. Why should it?

Exactly. Why should it? If you remove all logging concerns from the work
interface you don't do any assumptions about how logging is done. The
presence of getPseudoLogger(), though, produces a strong emphasis on
non-static logging.

> Third, lets define the "concern". My understanding of Separation
> of Concerns in this case is that FOrayFont owns the concern that a message
> needs to be logged, and that the client application owns the concern of how
> that logging should be accomplished.
> 
> In order to maintain that Separation of Concerns, one of two things must
> happen:
> 1. The client must tell the component how stuff should be logged.
> 2. The server must tell the client what should be logged.
> 
> This means some logging-related stuff will appear in the interface between
> the two.

Not IMO. It can be an implementation detail. See more below.

> The design considerations are as follows:
> 1. FOrayFont needs to be able to log messages.

For whom? For the developer or for the end-user? Because that's what
I've learned during the past months: That it should be well divided
between the two audiences. The speciality is that the developer doesn't
need a logger per processing run (i.e. non-static logging) and the
end-user often needs more than just pure S

Re: Logging for FOrayFont

[Vincent Hennebert]

I'm satisfied with your explanations. Please just add a 
LEVEL_DEBUG constant and I'm OK with your interface.



OK, I have added the constant LEVEL_DEBUG back, and have also added a new
one called LEVEL_TRACE.
PLEASE NOTE: LEVEL_DEBUG is now equal to LEVEL_FINER (it previously was
equal to LEVEL_FINEST), and LEVEL_TRACE has been set equal to LEVEL_FINEST.
These changes have been made to better accommodate what I understand the
Commons Logging levels to be.

This makes the Avalon mapping look like this:
FINEST  debug
FINER   debug
FINEinfo
CONFIG  info
INFOinfo
WARNING warn
SEVERE  error


That's fine for me!

Thank you,
Vincent

RE: Logging for FOrayFont

[Victor Mote]

Vincent Hennebert wrote:

> Victor Mote a écrit :
> > Actually there is not a level named "debug", although I might have 
> > defined that constant equal to "finest" in one of the 
> earlier versions.
> This does not appear in CVS. I would suggest you to redefine 
> such a constant to remove any ambiguity, as as you can see it 
> confused me.
> 
> > Here is the
> > way I mapped the Avalon levels in the AvalonLogger implementation:
> > 
> http://cvs.sourceforge.net/viewcvs.py/axsl/axsl/axsl-common/src/java/o
> > rg/axs l/common/AvalonLogger.java?view=markup
> > 
> > FINEST  debug
> > FINER   info
> > FINEinfo
> > CONFIG  info
> > INFOinfo
> > WARNING warn
> > SEVERE  error
> Why not. Is I know now that debug corresponds to finest I'll 
> follow the same scheme for commons Log.
> 
> > I don't really feel strongly about it either, but perhaps a 
> bit more 
> > strongly than you for the following reasons:
> > 1. From a sheer "standard" aspect, I wanted to stay as close to the 
> > Java logging system as possible. I would have used the 
> > java.util.logging.Level instances (for type safety) instead 
> of numeric 
> > constants, except for trying to retain Java 1.3 compatibility.
> > 2. I prefer to allow for more granularity rather than less (within 
> > reason), even if we don't think we need it right now.
> > 3. This is one of those things that you can change on 
> Tuesday to make 
> > one party happy, then change back again on Wednesday to 
> make another 
> > party happy, all for very little benefit. In short, there 
> is no way to 
> > make everyone happy.
> I understand your concerns and agree with them.
> 
> > 
> > Also, I don't know if you noticed the following methods:
> > info(String message)
> > warn(String message)
> > error(String message)
> > debug(String message)
> > which correspond directly to the Avalon methods of the same 
> name, and 
> > are intended to provide a sort of mapping for them.
> Certainly, but I also have to map the logMessage method...
> 
> > I don't mind adding one more
> > called trace(String message) if that would make the mapping concept 
> > more clear for you.
> Well, no need I think; as trace is below debug and debug is 
> mapped to finest, there is no corresponding log level for trace.
> 
> I'm satisfied with your explanations. Please just add a 
> LEVEL_DEBUG constant and I'm OK with your interface.

OK, I have added the constant LEVEL_DEBUG back, and have also added a new
one called LEVEL_TRACE.
PLEASE NOTE: LEVEL_DEBUG is now equal to LEVEL_FINER (it previously was
equal to LEVEL_FINEST), and LEVEL_TRACE has been set equal to LEVEL_FINEST.
These changes have been made to better accommodate what I understand the
Commons Logging levels to be.

This makes the Avalon mapping look like this:
FINEST  debug
FINER   debug
FINEinfo
CONFIG  info
INFOinfo
WARNING warn
SEVERE  error

Victor Mote

DO NOT REPLY [Bug 36508] - Padding-* attributes handling in RTF-rendering

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=36508





--- Additional Comments From [EMAIL PROTECTED]  2005-09-05 18:01 ---
Created an attachment (id=16311)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=16311&action=view)
[PATCH] Handling of padding attributes are supported

Was: 
padding-related attributes were ignored.

Became: 
When border is specified, all padding attributes are recognized.
When border is not specified, padding added to space-* attributes.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 36508] New: - Padding-* attributes handling in RTF-rendering

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=36508

   Summary: Padding-* attributes handling in RTF-rendering
   Product: Fop
   Version: all
  Platform: Other
OS/Version: other
Status: NEW
  Severity: normal
  Priority: P2
 Component: general
AssignedTo: fop-dev@xmlgraphics.apache.org
ReportedBy: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]


 

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

Re: [VOTE] Manuel Mall as new FOP committer

[Andreas L Delmelle]

On Sep 5, 2005, at 10:29, Jeremias Maerki wrote:


Manuel Mall ...



That's why I'd like to nominate him for
committership in Apache FOP.



Definitely a BIG +1 from me.

Cheers,

Andreas

DO NOT REPLY [Bug 36505] - [PATCH] SVG bugs in Java2D renderers

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=36505





--- Additional Comments From [EMAIL PROTECTED]  2005-09-05 17:23 ---
Created an attachment (id=16310)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=16310&action=view)
Patch for java2d/svg bugs


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 36505] New: - [PATCH] SVG bugs in Java2D renderers

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=36505

   Summary: [PATCH] SVG bugs in Java2D renderers
   Product: Fop
   Version: 1.0dev
  Platform: All
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: svg
AssignedTo: fop-dev@xmlgraphics.apache.org
ReportedBy: [EMAIL PROTECTED]


The following bugs have been found in the Java2D renderer's SVG handling:

1. Whenever two svg images appear on the same page, the second one disappears
completely. This was caused by the translate at the end of renderSVGDocument
method not being the correct inverse of the preceding one.

2. Any attempt to scale the image failed. Fixed by using the position's width
and height rather than the image's.

3. Any attempt to use an image larger than 100x100 caused erroneous cropping.
Fixed by scaling as above. However, if the image is larger than 100x100 and
no viewbox is defined in the svg file, cropping will still occur. This
restriction also holds for PDF (and other?) renderers.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

RE: Logging for FOrayFont

[Victor Mote]

Jeremias Maerki wrote:

> I got a little shock when I realized a problem I didn't think 
> of when we discussed moving FOP components over to XML 
> Graphics Commons. We said we would try to remove logging code 
> from these basic components entirely.
>
> Now, I forgot to consider the decision to use FOrayFont made earlier.
> The external dependency on FOrayFont also would be a problem 
> in itself because the Batik side has strong feelings against 
> external dependencies.
> We need to think about what to do about this WRT the PDF and 
> PS transcoders. Optimized text painting in these two 
> transcoders depends a lot on the font subsystem.

Well, the little change I just made removes entirely any dependency on
Avalon in any FOray code, except for the fact that Ant seems to need it for
logging (needed for creating hyphenation patterns and such). There is no
longer any Avalon code in FOrayFont. In fact, that was the primary
motivation for making the change. The Avalon Logger interface would have
been quite a sufficient solution for anything that FOray needs, and, since
it is an interface, adapters could be written from it to anything else, just
as Vincent and I have been discussing for the PseudoLogger interface.

> Aside from that, a thought about the aXSL APIs: Being an 
> ex-Avaloner SoC (separation of concerns) is a big concern to 
> me. The functional API of a package should IMO actually not 
> deal with (or rather expose) logging at all. It's a separate 
> concern. I'm ever growing more cofident that 
> developer-oriented logging should be done through a static 
> logging facility (like Commons Logging) and that 
> end-user-oriented logging needs to operate per processing run 
> (like Avalon Logger) but not necessarily through a standard 
> logging abstraction interface, but rather an 
> application-specific one that provides exactly what the 
> application needs to send feedback to the end-users. In that 
> light, a PDF or font library shouldn't expose any logging 
> facilities at all or at least to static logging that is 
> externally configured.

First, do you understand that the FOrayFont library does not "expose any
logging facilities" to the client, but instead asks the client to expose the
logging facilities to it? A PseudoLogger is required (but can be passed
null) in the FontServer constructor and is required in a method in
FontConsumer. But FontConsumer is implemented on the client side, in which
the client application tells FOray about itself.

Second, why should FOray limit its clients to only use static logging? If
the client has to expose a static logging mechanism to FOray in order to get
static logging to work, what can possibly be wrong with exposing a
non-static logging mechanism to FOray? Right now, FOray doesn't care whether
static or non-static logging is used. Why should it?

Third, lets define the "concern". My understanding of Separation
of Concerns in this case is that FOrayFont owns the concern that a message
needs to be logged, and that the client application owns the concern of how
that logging should be accomplished.

In order to maintain that Separation of Concerns, one of two things must
happen:
1. The client must tell the component how stuff should be logged.
2. The server must tell the client what should be logged.

This means some logging-related stuff will appear in the interface between
the two.

The design considerations are as follows:
1. FOrayFont needs to be able to log messages.
2. FOrayFont needs to be able to work with any client system, regardless of
their preferences on logging.

I can keep all logging internal to the FOrayFont subsystem, which would mean
that the client application (FOP) has no control over the logging
whatsoever. Very bad. FOray has to guess what kind of logger to use, and it
will never be right.

I can expose a logging interface that allows the client application to
handle logging its own way. This has been the approach used so far.

The only other solution is a bit more complex, and IMO, quickly becomes
ugly. FOrayFont currently asks some client object to implement the
FontConsumer interface. Instead of having FontConsumer provide a
PseudoLogger, it could have a method instead that logs messages:

/**
 * @param level An integer describing the level at which this message
should be logged,
 * that is, error, warning, debug, etc.
 */
public void logMessage(String message, int level) ;

The problem here is that I need to then create another interface that has
something similar that can pass itself to FontServer so that general (not
document-specific) logging messages can be handled. I also need to create
one for Graphics, Text, FOTree, etc. I will have 10 or 12 methods in various
interfaces that all do the same thing. This seems silly to me. This begs for
a type to do this, which the Avalon Logger interface provided and which
PseudoLogger provides as well.

Further, does a logMessage() method still expose logging functi

Re: e-g with padding and borders

[Manuel Mall]

On Mon, 5 Sep 2005 09:51 pm, Jeremias Maerki wrote:
> I think you're reaching a point where you should understand exactly
> how the Knuth model works. 

It had to happen eventually :-).

> I haven't looked at how conditionality is 
> implemented very closely. Without diving deeper into this myself I'm
> unable to help right now other than to point you to
> BlockStackingLayoutManager again which contains at least part of the
> code that deals with space conditionality. If the comments are right
> in BlockStackingLayoutManager conditionality has not even been
> implemented for blocks in the b-p-d.
>
> If you really want to go down that road I suggest you get Donald
> Knuth's "Digital Typography" or another book that contains the essay
> "Breaking Paragraphs into Lines". There may also be a little
> information about handling conditionality in the mailing list
> archives. Sorry that I can't help more, but we're getting into
> complicated terrain here.
>

That's fine - I am just trying to extract as much information as 
possible the "easy way" first. Also, even if conditionality is not 
implemented may be some of the original designers of the implementation 
would like to share their thoughts on this topic?

I'll see if I can get my hand on the book in the university library here 
(btw - I am in Perth - Western Australia).

In the meantime I'll stick with the "discard" model which happens to be 
the default anyway.

Manuel

> On 05.09.2005 14:52:23 Manuel Mall wrote:
> > On Mon, 5 Sep 2005 03:08 pm, Manuel Mall wrote:
> > > Jeremias,
> > >
> > > thanks for your patience in answering my questions.
> > >
> > > On Mon, 5 Sep 2005 02:51 pm, Jeremias Maerki wrote:
> > > > On 04.09.2005 16:34:35 Manuel Mall wrote:
> >
> > 
> >
> > > > > Another question for the "Knuth" experts. It appears the
> > > > > inline LMs don't make provisions in the IPD for
> > > > > borders/padding on inlines. I assume border/padding is
> > > > > logically like a   (with the width of the border +
> > > > > padding) in front of the first and after the last character
> > > > > of the inline assuming
> > > > > .conditionality=discard, that is we don't want to have let's
> > > > > say a left border alone on the end of a line with the text
> > > > > starting on the next. For .conditionality=retain this width
> > > > > needs to be reserved as well at the beginning and end of each
> > > > > intermediate line. Any suggestions how this can/should be
> > > > > integrated into the linebreaking algorithm?
> > > >
> > > > Exactly like spaces, borders and padding in b-p-d for
> > > > block-level objects: additional auxiliary boxes and penalties.
> > > > See BlockStackingLayoutManager.addKnuthElementsFor*(). Line
> > > > breaking is the same as page breaking, only in a different
> > > > direction.
> > >
> > > Thanks for the pointer. I'll have a look at that.
> >
> > That seem to have done the trick. I have copied the Border/Padding
> > before/after logic from BlockStackingLayoutManager and made it into
> > a Border/Padding start/end for the Inline LM. There were some side
> > effects in that the Line LM expectd only KnuthInlineBoxes and now
> > we have some KnuthBoxes as well but I think I solved that ok.
> >
> > Next problem: border conditionality - how do I model that with the
> > Knuth approach? At the time I add the Border/Padding start/end
> > boxes we don't have line breaks so they really only cover the
> > .conditionality=discard case. How do I tell the algorithm to leave
> > enough space at the end of each line (and the beginning of the next
> > line) for the borders (in the case of .conditionality=retain)?
> >
> > > > 
> > > >
> > > >
> > > > Jeremias Maerki
> > >
> > > Manuel
> >
> > Manuel
>
> Jeremias Maerki

Re: SVG Image cropping/positioning

[Luca Furini]

Richard W. wrote:


I'm starting now. I've had to rename inline_block_nested_\#36248.xml
to inline_block_nested_bug36248.xml to get the junit task to build.


I had to rename that file too; I have win xp.

Regards
Luca

Re: SVG Image cropping/positioning

[Jeremias Maerki]

Fixed:
http://svn.apache.org/viewcvs?rev=278753&view=rev
http://svn.apache.org/viewcvs?rev=278754&view=rev

On 05.09.2005 15:53:47 richardw wrote:
> Jeremias Maerki writes:
>  > > > I'm starting now. I've had to rename inline_block_nested_\#36248.xml
>  > > > to inline_block_nested_bug36248.xml to get the junit task to build.
>  > 
>  > Unix Which OS?
> 
> Linux,
> 
> Richard



Jeremias Maerki

Re: e-g with padding and borders

[Chris Bowditch]

Jeremias Maerki wrote:


I think you're reaching a point where you should understand exactly how
the Knuth model works. I haven't looked at how conditionality is
implemented very closely. Without diving deeper into this myself I'm
unable to help right now other than to point you to
BlockStackingLayoutManager again which contains at least part of the
code that deals with space conditionality. If the comments are right in
BlockStackingLayoutManager conditionality has not even been implemented
for blocks in the b-p-d.


We discussed this just the other day, and I thought the outcome was that 
space conditionality for blocks in bpd is implemented, but precedence 
isn't yet.




Chris

Re: SVG Image cropping/positioning

[Chris Bowditch]

Jeremias Maerki wrote:



ipda is the absolute position in the Inline Progress Dimension (x coord 
in Left to Right Mode)



Nope. ipda is the allocated inline-progression-dimension which is the
"ipd" above plus the start and end border and padding widths, i.e. the
allocation rectangle. "a" stands for allocation. It is a bit unclear
right now which allocation rectangle is meant here. There are several
different allocation rectangles defined in the spec.


Ooppss. Oh well, Ive learnt something new.

Thanks,

Chris

Re: SVG Image cropping/positioning

[richardw]

Jeremias Maerki writes:
 > > > I'm starting now. I've had to rename inline_block_nested_\#36248.xml
 > > > to inline_block_nested_bug36248.xml to get the junit task to build.
 > 
 > Unix Which OS?

Linux,

Richard

Re: e-g with padding and borders

[Jeremias Maerki]

I think you're reaching a point where you should understand exactly how
the Knuth model works. I haven't looked at how conditionality is
implemented very closely. Without diving deeper into this myself I'm
unable to help right now other than to point you to
BlockStackingLayoutManager again which contains at least part of the
code that deals with space conditionality. If the comments are right in
BlockStackingLayoutManager conditionality has not even been implemented
for blocks in the b-p-d.

If you really want to go down that road I suggest you get Donald Knuth's
"Digital Typography" or another book that contains the essay "Breaking
Paragraphs into Lines". There may also be a little information about
handling conditionality in the mailing list archives. Sorry that I can't
help more, but we're getting into complicated terrain here.

On 05.09.2005 14:52:23 Manuel Mall wrote:
> On Mon, 5 Sep 2005 03:08 pm, Manuel Mall wrote:
> > Jeremias,
> >
> > thanks for your patience in answering my questions.
> >
> > On Mon, 5 Sep 2005 02:51 pm, Jeremias Maerki wrote:
> > > On 04.09.2005 16:34:35 Manuel Mall wrote:
> 
> > > > Another question for the "Knuth" experts. It appears the inline
> > > > LMs don't make provisions in the IPD for borders/padding on
> > > > inlines. I assume border/padding is logically like a   (with
> > > > the width of the border + padding) in front of the first and
> > > > after the last character of the inline assuming
> > > > .conditionality=discard, that is we don't want to have let's say
> > > > a left border alone on the end of a line with the text starting
> > > > on the next. For .conditionality=retain this width needs to be
> > > > reserved as well at the beginning and end of each intermediate
> > > > line. Any suggestions how this can/should be integrated into the
> > > > linebreaking algorithm?
> > >
> > > Exactly like spaces, borders and padding in b-p-d for block-level
> > > objects: additional auxiliary boxes and penalties. See
> > > BlockStackingLayoutManager.addKnuthElementsFor*(). Line breaking is
> > > the same as page breaking, only in a different direction.
> >
> > Thanks for the pointer. I'll have a look at that.
> >
> 
> That seem to have done the trick. I have copied the Border/Padding 
> before/after logic from BlockStackingLayoutManager and made it into a 
> Border/Padding start/end for the Inline LM. There were some side 
> effects in that the Line LM expectd only KnuthInlineBoxes and now we 
> have some KnuthBoxes as well but I think I solved that ok.
> 
> Next problem: border conditionality - how do I model that with the Knuth 
> approach? At the time I add the Border/Padding start/end boxes we don't 
> have line breaks so they really only cover the .conditionality=discard 
> case. How do I tell the algorithm to leave enough space at the end of 
> each line (and the beginning of the next line) for the borders (in the 
> case of .conditionality=retain)?
> 
> > > 
> > >
> > >
> > > Jeremias Maerki
> >
> > Manuel
> 
> Manuel



Jeremias Maerki

Re: SVG Image cropping/positioning

[Jeremias Maerki]

On 05.09.2005 15:30:20 Chris Bowditch wrote:
> [EMAIL PROTECTED] wrote:
> 
> > Jeremias Maerki writes:
> >  > I haven't found anything odd, yet. Looking forward to your test cases.
> > 
> > I'm starting now. I've had to rename inline_block_nested_\#36248.xml
> > to inline_block_nested_bug36248.xml to get the junit task to build.

Unix Which OS?

> > Can you please point me to an explaination of the following:
> > 
> >   
> > 
> >  > xpath="//flow/block[2]/lineArea/viewport/@ipda"/>
> > 
> >  > xpath="//flow/block[2]/lineArea/viewport/@bpda"/>
> >   
> > 
> > i.e. What are ipd, bpda, etc. ?
> 
> ipd (in Left to Right mode) is width of the Area.

ipd = short for inline-progression-dimension.

ipd here is  the extent in inline-progression-dimension of the
content-rectangle of an area.

> bpd (in Left to Right mode) is the height of the Area

ipd = short for block-progression-dimension.

bpd here is  the extent in block-progression-dimension of the
content-rectangle of an area.

> ipda is the absolute position in the Inline Progress Dimension (x coord 
> in Left to Right Mode)

Nope. ipda is the allocated inline-progression-dimension which is the
"ipd" above plus the start and end border and padding widths, i.e. the
allocation rectangle. "a" stands for allocation. It is a bit unclear
right now which allocation rectangle is meant here. There are several
different allocation rectangles defined in the spec.

> bpda is the absolute position in the Block Progression Dimension (y 
> coord in Left to Right Mode)

Same here. bpda is bpd + before|after border and padding width.

Note that the area tree does not have any explicit X and Y coordinates
except for the absolute or fixed positioning of block-containers and
these coordinates are still always relative to a specific point. All
other coordinates in the area are only implicitely known by the
renderers which keep track using the currentBPPosition and
currentIPPosition member variables.


Jeremias Maerki

Re: SVG Image cropping/positioning

[Chris Bowditch]

[EMAIL PROTECTED] wrote:


Jeremias Maerki writes:
 > I haven't found anything odd, yet. Looking forward to your test cases.

I'm starting now. I've had to rename inline_block_nested_\#36248.xml
to inline_block_nested_bug36248.xml to get the junit task to build.

Can you please point me to an explaination of the following:

  




  

i.e. What are ipd, bpda, etc. ?


ipd (in Left to Right mode) is width of the Area.
bpd (in Left to Right mode) is the height of the Area
ipda is the absolute position in the Inline Progress Dimension (x coord 
in Left to Right Mode)
bpda is the absolute position in the Block Progression Dimension (y 
coord in Left to Right Mode)


Chris

Re: SVG Image cropping/positioning

[richardw]

Jeremias Maerki writes:
 > I haven't found anything odd, yet. Looking forward to your test cases.

I'm starting now. I've had to rename inline_block_nested_\#36248.xml
to inline_block_nested_bug36248.xml to get the junit task to build.

Can you please point me to an explaination of the following:

  




  

i.e. What are ipd, bpda, etc. ?

Richard

Re: e-g with padding and borders

[Manuel Mall]

On Mon, 5 Sep 2005 03:08 pm, Manuel Mall wrote:
> Jeremias,
>
> thanks for your patience in answering my questions.
>
> On Mon, 5 Sep 2005 02:51 pm, Jeremias Maerki wrote:
> > On 04.09.2005 16:34:35 Manuel Mall wrote:

> > > Another question for the "Knuth" experts. It appears the inline
> > > LMs don't make provisions in the IPD for borders/padding on
> > > inlines. I assume border/padding is logically like a   (with
> > > the width of the border + padding) in front of the first and
> > > after the last character of the inline assuming
> > > .conditionality=discard, that is we don't want to have let's say
> > > a left border alone on the end of a line with the text starting
> > > on the next. For .conditionality=retain this width needs to be
> > > reserved as well at the beginning and end of each intermediate
> > > line. Any suggestions how this can/should be integrated into the
> > > linebreaking algorithm?
> >
> > Exactly like spaces, borders and padding in b-p-d for block-level
> > objects: additional auxiliary boxes and penalties. See
> > BlockStackingLayoutManager.addKnuthElementsFor*(). Line breaking is
> > the same as page breaking, only in a different direction.
>
> Thanks for the pointer. I'll have a look at that.
>

That seem to have done the trick. I have copied the Border/Padding 
before/after logic from BlockStackingLayoutManager and made it into a 
Border/Padding start/end for the Inline LM. There were some side 
effects in that the Line LM expectd only KnuthInlineBoxes and now we 
have some KnuthBoxes as well but I think I solved that ok.

Next problem: border conditionality - how do I model that with the Knuth 
approach? At the time I add the Border/Padding start/end boxes we don't 
have line breaks so they really only cover the .conditionality=discard 
case. How do I tell the algorithm to leave enough space at the end of 
each line (and the beginning of the next line) for the borders (in the 
case of .conditionality=retain)?

> > 
> >
> >
> > Jeremias Maerki
>
> Manuel

Manuel

DO NOT REPLY [Bug 36480] - [PATCH] Space support in RTF rendering

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=36480


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |NEEDINFO




--- Additional Comments From [EMAIL PROTECTED]  2005-09-05 13:58 ---
Sergey, in order to apply this patch I need to ask you a couple of things:
- The patch contains a new file so we need an ICLA (Individual Contributor
License Agreement) from you on file with the ASF. The other patches on existing
files went under section 5 of the ALv2, but new files don't. The policy about
this has been tightened up lately. You will also need to check if Borland, your
employer, should also file a CCLA (Corporate CLA) with the ASF. I'm sorry about
the inconvenience. More information can be found under
http://www.apache.org/licenses/. If you have any questions, please get back to 
me.
- Would you please resubmit the patch against the latest SVN Trunk as soon as
you've submitted the ICLA and attach the boiler plate license header with the
copyright year "2005" to the new file?

Thanks very much for your contributions so far. They've fixed a few important
problems with RTF output.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 36479] - [PATCH] Bookmarks don't work in RTF rendering

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=36479


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2005-09-05 13:45 ---
Applied. Thanks!

http://svn.apache.org/viewcvs?rev=278724&view=rev

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 36476] - [PATCH] Border attributes handling in RTF rendering

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=36476


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2005-09-05 13:35 ---
Applied. Thanks!

http://svn.apache.org/viewcvs?rev=278720&view=rev

A comment: It is important to note that the grouping of borders among
consecutive blocks with the same border specifications violates the XSL-FO
specifications. I found an RTF command in the RTF spec v1.7 ("brdrbtw") which
seems to address this but I couldn't make it work.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

Re: [VOTE] Manuel Mall as new FOP committer

[Finn Bock]

[Jeremias]


Manuel Mall has been investing a tremendous amount of time and effort
into making FOP better lately. The results were just great. It's been a
pleasure to apply his patches, even though it ate up a lot of my time.
;-) Manuel has been around since at least late 2002, even submitted a
patch back then. He shows a good understanding of how things work in our
project and is quick to learn in other areas. He doesn't fear diving
into the code of the layout engine. That's exactly the sort of people we
need in the project team. That's why I'd like to nominate him for
committership in Apache FOP.


+1

regards,
finn

DO NOT REPLY [Bug 36477] - [PATCH] Start-indent and end-indent attributes in RTF rendering

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=36477


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2005-09-05 13:31 ---
Applied. Thanks.

http://svn.apache.org/viewcvs?rev=278720&view=rev

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 36476] - [PATCH] Border attributes handling in RTF rendering

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=36476





--- Additional Comments From [EMAIL PROTECTED]  2005-09-05 12:08 ---
Created an attachment (id=16307)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=16307&action=view)
RTF output after patch


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 36476] - [PATCH] Border attributes handling in RTF rendering

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=36476





--- Additional Comments From [EMAIL PROTECTED]  2005-09-05 12:07 ---
Created an attachment (id=16306)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=16306&action=view)
RTF output before patch


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

Re: [VOTE] Manuel Mall as new FOP committer

[Christian Geisert]

Jeremias Maerki schrieb:
> Manuel Mall has been investing a tremendous amount of time and effort
> into making FOP better lately. The results were just great. It's been a
> pleasure to apply his patches, even though it ate up a lot of my time.
> ;-) Manuel has been around since at least late 2002, even submitted a
> patch back then. He shows a good understanding of how things work in our
> project and is quick to learn in other areas. He doesn't fear diving
> into the code of the layout engine. That's exactly the sort of people we
> need in the project team. That's why I'd like to nominate him for
> committership in Apache FOP.

And as he stated his goal is to help to "get FOP 1.0 out of the door in
a relatively short timeframe (meaning months not years)"

+1

Christian

DO NOT REPLY [Bug 36475] - Background-color attribute handling for fo:block in RTF rendering

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=36475


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2005-09-05 11:03 ---
Applied. Thanks a lot.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 36475] - Background-color attribute handling for fo:block in RTF rendering

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=36475





--- Additional Comments From [EMAIL PROTECTED]  2005-09-05 11:00 ---
Created an attachment (id=16305)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=16305&action=view)
RTF output after patch


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

Re: Logging for FOrayFont

[Chris Bowditch]

Jeremias Maerki wrote:


I got a little shock when I realized a problem I didn't think of when we
discussed moving FOP components over to XML Graphics Commons. We said we
would try to remove logging code from these basic components entirely.
Now, I forgot to consider the decision to use FOrayFont made earlier.
The external dependency on FOrayFont also would be a problem in itself
because the Batik side has strong feelings against external dependencies.
We need to think about what to do about this WRT the PDF and PS
transcoders. Optimized text painting in these two transcoders depends a
lot on the font subsystem.


Ouch! The FORayFont integration offers a hugh functional benefit over 
the current Font code, so it would be a real shame to lose it. IIRC 
Thomas was saying that he was against dependencies that don't yield any 
functional benefit, i.e. logging and avalon framework. Since FORayFont 
does have functional benefits for both projects perhaps it won't be such 
a problem for Batik to include it. But I guess that is up the Batik team 
to decide.




Chris

DO NOT REPLY [Bug 36475] - Background-color attribute handling for fo:block in RTF rendering

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=36475





--- Additional Comments From [EMAIL PROTECTED]  2005-09-05 10:59 ---
Created an attachment (id=16304)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=16304&action=view)
RTF output before patch


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

Re: [VOTE] Manuel Mall as new FOP committer

[Chris Bowditch]

Jeremias Maerki wrote:


Manuel Mall has been investing a tremendous amount of time and effort
into making FOP better lately. The results were just great. It's been a
pleasure to apply his patches, even though it ate up a lot of my time.
;-) Manuel has been around since at least late 2002, even submitted a
patch back then. He shows a good understanding of how things work in our
project and is quick to learn in other areas. He doesn't fear diving
into the code of the layout engine. That's exactly the sort of people we
need in the project team. That's why I'd like to nominate him for
committership in Apache FOP.


+1 from me. Congratulations Manuel! Your work is nothing short of 
brilliant and your committership is well deserved.


Chris

[VOTE] Manuel Mall as new FOP committer

[Luca Furini]

Jeremias Maerki wrote:


That's why I'd like to nominate him for committership in Apache FOP.


+1

Luca