text-decoration
Fop-devs, In spite of the huffing and puffing, my original implementation of text-decoration was wrong. Such hubris. Currently being corrected in Defoe. Peter
Re: Implementing text-decoration
I looked at the code and I can't see anything wrong with your suggestion. Unfortunately I'm far from an expert in this area of the code. Glen --- Jeremias Maerki [EMAIL PROTECTED] wrote: I'm currently looking at implementing text-decoration. ATM it's specified as an EnumProperty but should be more like a set of enums with certain validation rules applied. I'm unsure about the approach. If anyone already has an idea how it should look like I'd appreciate any insight. My first idea was to implement a special property class (TextDecorationProperty) that handles the conversion of a ListProperty of NCNames to an internal set of variables while at the same time validating the enum combinations. I think my approach would work even if it look a bit awkward. But I wanted to check first so I didn't implement something really ugly. Jeremias Maerki
Implementing text-decoration
I'm currently looking at implementing text-decoration. ATM it's specified as an EnumProperty but should be more like a set of enums with certain validation rules applied. I'm unsure about the approach. If anyone already has an idea how it should look like I'd appreciate any insight. My first idea was to implement a special property class (TextDecorationProperty) that handles the conversion of a ListProperty of NCNames to an internal set of variables while at the same time validating the enum combinations. I think my approach would work even if it look a bit awkward. But I wanted to check first so I didn't implement something really ugly. Jeremias Maerki
RE: Implementing text-decoration
Jeremias Maerki wrote: I'm currently looking at implementing text-decoration. ATM it's specified as an EnumProperty but should be more like a set of enums with certain validation rules applied. I'm unsure about the approach. If anyone already has an idea how it should look like I'd appreciate any insight. My first idea was to implement a special property class (TextDecorationProperty) that handles the conversion of a ListProperty of NCNames to an internal set of variables while at the same time validating the enum combinations. I think my approach would work even if it look a bit awkward. But I wanted to check first so I didn't implement something really ugly. I think you are on the right track, and it is a curiosity to me why the standard writers did not create a separate datatype for this. The FOray implementation uses a pseudo datatype to handle text decoration, handled the same general way that keeps and spaces are: http://cvs.sourceforge.net/viewcvs.py/foray/foray/foray-fotree/src/java/org/ foray/fotree/value/DtTextDeco.java?view=markup The class that creates and uses the datatype is here: http://cvs.sourceforge.net/viewcvs.py/foray/foray/foray-fotree/src/java/org/ foray/fotree/fo/prop/TextDecoration.java?view=markup After taking this approach (i.e. allowing all of the variations to be stored together), text decoration was implemented properly. IOW, all of the other pieces were already in place, all I had to do was get the data stored and retrieved correctly. Caveat: FOray stores and retrieves properties using a late- or no-binding scheme, so the timing will be different, but I would think the general principle would be the same. HTH. Victor Mote
Re: Implementing text-decoration
Victor Mote wrote: Jeremias Maerki wrote: I'm currently looking at implementing text-decoration. ATM it's specified as an EnumProperty but should be more like a set of enums with certain validation rules applied. I'm unsure about the approach. If anyone already has an idea how it should look like I'd appreciate any insight. My first idea was to implement a special property class (TextDecorationProperty) that handles the conversion of a ListProperty of NCNames to an internal set of variables while at the same time validating the enum combinations. I think my approach would work even if it look a bit awkward. But I wanted to check first so I didn't implement something really ugly. I think you are on the right track, and it is a curiosity to me why the standard writers did not create a separate datatype for this. The FOray implementation uses a pseudo datatype to handle text decoration, handled the same general way that keeps and spaces are: http://cvs.sourceforge.net/viewcvs.py/foray/foray/foray-fotree/src/java/org/ foray/fotree/value/DtTextDeco.java?view=markup The class that creates and uses the datatype is here: http://cvs.sourceforge.net/viewcvs.py/foray/foray/foray-fotree/src/java/org/ foray/fotree/fo/prop/TextDecoration.java?view=markup After taking this approach (i.e. allowing all of the variations to be stored together), text decoration was implemented properly. IOW, all of the other pieces were already in place, all I had to do was get the data stored and retrieved correctly. Caveat: FOray stores and retrieves properties using a late- or no-binding scheme, so the timing will be different, but I would think the general principle would be the same. And of course, alt-design had a solution for this, oh, a long, long time ago. It can be found in the usual place, and was even mentioned on the list. That's two solutions so far, and counting. Peter
DO NOT REPLY [Bug 25275] New: - fo:page-number ignores text-decoration=underline attribute
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25275. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25275 fo:page-number ignores text-decoration=underline attribute Summary: fo:page-number ignores text-decoration=underline attribute Product: Fop Version: 0.20.5 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: pdf renderer AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Have got the header format for a pdf manual set as follows: xsl:attribute-set name=header.content.properties xsl:attribute name=font-size9pt/xsl:attribute xsl:attribute name=text-decorationunderline/xsl:attribute /xsl:attribute-set The problem that I'm getting is that the page number is not underlined, but the rest of the text is. The part of the header content code that produces the example header is (using docbook xml and the 1.62.4 XSL stylesheets): xsl:when test=$sequence = 'even' and $position = 'left' fo:page-number/ fo:inline - /fo:inline fo:inline xsl:call-template name=header.component.title xsl:with-param name=node select=ancestor-or-self::book[1]/ /xsl:call-template /fo:inline /xsl:when I've tried modifying the page-number call as follows: fo:page-number text-decoration=underline/ And: fo:inline text-decoration=underlinefo:page-number//fo:inline And: xsl:when test=$sequence = 'even' and $position = 'left' fo:block text-decoration=underline fo:page-number/ fo:inline - /fo:inline fo:inline xsl:call-template name=header.component.title xsl:with-param name=node select=ancestor-or-self::book[1]/ /xsl:call-template /fo:inline /fo:block /xsl:when And: xsl:when test=$sequence = 'even' and $position = 'left' fo:inline text-decoration=underline fo:page-number/ fo:inline - /fo:inline fo:inline xsl:call-template name=header.component.title xsl:with-param name=node select=ancestor-or-self::book[1]/ /xsl:call-template /fo:inline /fo:inline /xsl:when The text-decoration property on the fo:page-number element is being passed into fop, but the page number is consistently being rendered without the underline.
RE: thoughts on fonts (was: text-decoration)
Jeremias Maerki wrote:
Can we sketch that on the Wiki in some simple way? Defining some Java
interfaces and things like that? Anyway, as you mentioned we should sort
out things like Session and Document on another page first.
OK, I just put a proposal out there in the section discussing Facade. More
on this below.
It would be great if you would read up on Avalon a bit.
I assume that we are talking about the Framework stuff here. I still haven't
found the ServiceManager that you mentioned.
Do I get you right that you would get something like that?
public interface Font {
String getFontName();
int getFontWeight();
int getFontSize();
FontMetrics getFontMetricsForLayout();
}
public interface FontMetrics {
//These methods already take font size into account
int getAscender();
int getDescender();
int getCapHeight();
//more...
int getWidth(char c);
boolean hasKerningAvailable();
//more...
}
That looks promising.
See the wiki where I have added a couple of things to your outline above.
The main difference is that I am not thinking of it as an interface, because
I only ever want one implementation. The concrete class is itself the
interface that the remainder of the system uses. My un-OOP (but not
anti-OOP) background is probably showing through here, so please talk me out
of this if I am out of line. The reason for my approach is that ideally,
what we might want here is for java.awt.Font to be in implementation of the
interface that we wish to use. That is not an option. So what we are
building is a /virtual/ interface that we can hide java.awt.Font and /all/
other font concepts behind. We are trying to find commonality between
objects that have similar real-world characteristics, but that have no
compiler-level common heritage. There may be a better way.
Yes, I share your unease, but I look at it from this side: Multiple area
trees mean possibly different layout which can be a problem when you're
working in an environment where you're working with legally relevant
documents. Two generated documents from the same source must be as equal
as possible. (funny use of equal, I know)
I guess what I am saying is that different fonts used will probably /force/
different area trees. So, from out standpoint, better to disallow it than to
disappoint.
Sorry to be so slow in responding.
Victor Mote
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: thoughts on fonts (was: text-decoration)
On 13.01.2003 19:18:18 Victor Mote wrote:
Jeremias Maerki wrote:
Can we sketch that on the Wiki in some simple way? Defining some Java
interfaces and things like that? Anyway, as you mentioned we should sort
out things like Session and Document on another page first.
OK, I just put a proposal out there in the section discussing Facade. More
on this below.
Mh, yes, I'm not so happy about it, yet. I'll add my comments as
soon as my current task is done.
It would be great if you would read up on Avalon a bit.
I assume that we are talking about the Framework stuff here. I still haven't
found the ServiceManager that you mentioned.
Yes, we're talking about Framework. Framework defines the contracts in
an Avalon system which includes ServiceManager. ServiceManager is the
successor to the ComponentManager which was deprecated because every
service/component had to implement a Component marker interface with no
methods. The ServiceManager now returns simple Objects that need to be
casted to their work interface.
Here's the link to the API docs of the Service package.
http://jakarta.apache.org/avalon/api/org/apache/avalon/framework/service/package-summary.html
See here for the Developing with Avalon guide:
http://jakarta.apache.org/avalon/developing/framework.html
(this is a MUST read)
Do I get you right that you would get something like that?
public interface Font {
String getFontName();
int getFontWeight();
int getFontSize();
FontMetrics getFontMetricsForLayout();
}
public interface FontMetrics {
//These methods already take font size into account
int getAscender();
int getDescender();
int getCapHeight();
//more...
int getWidth(char c);
boolean hasKerningAvailable();
//more...
}
That looks promising.
See the wiki where I have added a couple of things to your outline above.
The main difference is that I am not thinking of it as an interface, because
I only ever want one implementation. The concrete class is itself the
interface that the remainder of the system uses. My un-OOP (but not
anti-OOP) background is probably showing through here, so please talk me out
of this if I am out of line.
I guess I will. :-)
The reason for my approach is that ideally,
what we might want here is for java.awt.Font to be in implementation of the
interface that we wish to use. That is not an option. So what we are
building is a /virtual/ interface that we can hide java.awt.Font and /all/
other font concepts behind. We are trying to find commonality between
objects that have similar real-world characteristics, but that have no
compiler-level common heritage. There may be a better way.
There, you are on the right track IMO.
Yes, I share your unease, but I look at it from this side: Multiple area
trees mean possibly different layout which can be a problem when you're
working in an environment where you're working with legally relevant
documents. Two generated documents from the same source must be as equal
as possible. (funny use of equal, I know)
I guess what I am saying is that different fonts used will probably /force/
different area trees. So, from out standpoint, better to disallow it than to
disappoint.
I guess Peter is right that we have to keep it simple for now. Let's
stay on the safe side and be ready to adapt to future changes.
Sorry to be so slow in responding.
No problem. There's so much to do that I'm not getting stuck.
Sorry for not immediately answering in more detail. I've got to get my
head clear for that first.
Jeremias Maerki
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: thoughts on fonts (was: text-decoration)
On 11.01.2003 18:35:37 Victor Mote wrote:
Keiron Liddle wrote:
If I understand it correctly we could have:
- multiple output targets for one rendering run
- targets with the same font metrics can layout to a common area tree
- targets with similar or substitute metrics could force layout
to one area tree
- other targets can have different area trees from the same fo tree
There are some big picture things that we should probably address:
1. (Biggest of all) Do we have users that need to be able to do this? Are
the performance gains that they might get worth the pain on our end?
The performance gain is not having to do the layout for each output
document which is the major part of a processing run.
The system I wrote for my former employer which is a solution for
high-volume digital printing had to provide a minimal number of pages
per minute. That's usually about 1 to 2 times the speed of the target
printer. So if you have a Xerox DocuTech with 180 pages per minute
and you have to fill an archive with a different format than the one
sent to the printer you'll be happy for such a feature. Especially, if
legal requirements dictate that you need to be able to reprint the
document from the archive and get the same document almost to the pixel.
I'd say we need to be able to do this sometime in the future but not
necessarily now. So let's just make sure this requirement doesn't get
lost and that it stays in the back of our minds when we design the new
thing.
2. If we have a RenderingContext concept, doesn't that mean that we need to
know what that RenderingContext is for each output target before we start
processing? To do any good, we must sort like RenderingContexts process
them together. Since we don't complete parsing of the document until the
very end, it seems like we would have to parse the complete document before
knowing what the Context looks like.
That's bad, yes.
Or you could only allow one RenderingContext which results in a
restriction of the available fonts based on the output handlers. You'd
get an error message as soon as an unsupported font is used. When a
common set isn't possible you have to do two rendering runs anyway so we
might just as well delegate this to the caller/user.
3. If we were to switch to a model that completely parses the document at
the beginning (looking for RenderingContext differences), then we might want
to build the FO tree at the same time?
Won't be necessary with my alternative apporach above. But if the user
has to run the layout twice it might be good if the FO tree wasn't lost
between runs.
4. If we build the FO tree up front let it persist, then you can achieve
the same thing in series instead of in parallel. (All of this comes at the
price of greater memory consumption, or else caching). For example:
parse doc, build FO tree, build RenderingContexts
for each RenderingContext {
build an area tree
for each output medium in this RenderingContext {
render
}
delete area tree
}
Even in this serial design, you could multi-thread either or both of the two
loops.
It is very possible that I am missing something, but our memory-lean
event-based model would seem to dictate either 1) parsing the document
twice, or 2) not allowing multiple output formats in the same document.
I think my approach could work in this regard. I'm not sure. We can let
the FO tree live for another layout run, can't we?
Jeremias Maerki
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: thoughts on fonts (was: text-decoration)
Victor Mote wrote: Jeremias Maerki wrote: It is very possible that I am missing something, but our memory-lean event-based model would seem to dictate either 1) parsing the document twice, or 2) not allowing multiple output formats in the same document. I think my approach could work in this regard. I'm not sure. We can let the FO tree live for another layout run, can't we? I have no objection to it. However, AFAIK our processor doesn't really process an FO tree, it processes events that occur as the FO tree is built. So, you need to add something that walks through the existing FO tree starts creating events to feed into our processor. I don't know how much faster this might be than just reprocessing the original input. Then you need something in the process that says Oh, don't try to build an FO tree here, it already exists. In other words, we're kind of trying to reuse something that we didn't use the first time -- it all seems kind of klunky. It seems to me that if we want to go down that path, we would do well to build an FO tree up front, caching it for those who need a lean memory environment, then process that tree n times, all the same way. I am not really arguing for that, but merely pointing out that it seems like that is where reusing the FO tree leads us. There's one in alt.design if you ever need it. Peter -- Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/ Lord, to whom shall we go? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: thoughts on fonts (was: text-decoration)
Keiron Liddle wrote:
If I understand it correctly we could have:
- multiple output targets for one rendering run
- targets with the same font metrics can layout to a common area tree
- targets with similar or substitute metrics could force layout
to one area tree
- other targets can have different area trees from the same fo tree
There are some big picture things that we should probably address:
1. (Biggest of all) Do we have users that need to be able to do this? Are
the performance gains that they might get worth the pain on our end?
2. If we have a RenderingContext concept, doesn't that mean that we need to
know what that RenderingContext is for each output target before we start
processing? To do any good, we must sort like RenderingContexts process
them together. Since we don't complete parsing of the document until the
very end, it seems like we would have to parse the complete document before
knowing what the Context looks like.
3. If we were to switch to a model that completely parses the document at
the beginning (looking for RenderingContext differences), then we might want
to build the FO tree at the same time?
4. If we build the FO tree up front let it persist, then you can achieve
the same thing in series instead of in parallel. (All of this comes at the
price of greater memory consumption, or else caching). For example:
parse doc, build FO tree, build RenderingContexts
for each RenderingContext {
build an area tree
for each output medium in this RenderingContext {
render
}
delete area tree
}
Even in this serial design, you could multi-thread either or both of the two
loops.
It is very possible that I am missing something, but our memory-lean
event-based model would seem to dictate either 1) parsing the document
twice, or 2) not allowing multiple output formats in the same document.
Victor Mote
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: text-decoration
Keiron Liddle wrote: Have you managed to work out how the underline/overline should work, for example when there are embedded inline areas that contain a different font, colour or baseline. Well, not really. I just wanted to make something simple done :) afaiu different font/colour/etc embedded inlines will generate different Word with different traits, right? -- Oleg Tkachenko eXperanto team Multiconn Technologies, Israel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: thoughts on fonts (was: text-decoration)
Victor Mote wrote: There are some big picture things that we should probably address: 1. (Biggest of all) Do we have users that need to be able to do this? Are the performance gains that they might get worth the pain on our end? Apart from this is the fact that our processing model for any rendering is still very much in a state of flux. It may be less painful to retro-fit when we have a comprehensive working renderer, keeping this possibility in mind as we go. Peter -- Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/ Lord, to whom shall we go? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: thoughts on fonts (was: text-decoration)
Hi Victor
On 09.01.2003 19:09:17 Victor Mote wrote:
snip/
Let me say up front that I am going to follow your lead here.
I'm not taking the lead. We'll work together on this. I see that you
have some ideas yourself, so let's see what we can come up with together.
As far as I can see from your comments we will complement each other
nicely.
However, from
a design standpoint, the interface between Font stuff and the rest of FOP
seems really simple -- 1) layout needs a method that it passes font
descriptions to, and that it gets a Font object back; 3) layout needs font
metric information; 3) the renderers need a list of fonts that need to be
embedded. /Everything/ else can be hidden, including FontMetrics. Also, all
of the differences between font types can be hidden behind this same facade.
Can we sketch that on the Wiki in some simple way? Defining some Java
interfaces and things like that? Anyway, as you mentioned we should sort
out things like Session and Document on another page first.
I don't like FontInfo. I want that to be an interface. Last night, I've
come up with a few ideas that I'm going to add to the Wiki page. There's
more and more Avalon that should be taken into account. I'm slowly
starting to understand how Avalon can be used within FOP.
Avalon is one area that I need to get up to speed on. The other is (and
someone mentioned this several weeks ago), how Batik uses fonts, and to see
whether we can share/use some of their work.
It would be great if you would read up on Avalon a bit.
With regard to FontInfo being an interface, I thought the data in it simply
became part of the Session and Document concepts.
Something along these lines, yes.
I think the FontMetrics should eventually be seen only by the
Font object.
However, it might need to be a Facade itself to deal with the
different ways
font metric information can be returned.
No, I think it's the other way around. FontMetrics should only be seen
by the layout engine. I don't even know what a Font object will be.
We'll have to define what a Font object is, if something like that will
ever exist. The Font object for me is just an implementation of a font.
Nothing that will be used directly, at least by the layout engine, well,
probably by the output handlers that need to access a myriad of values
for font registration.
OK, I have not made myself clear. First, see the wiki glossary, where I have
added definitions for font and typeface to try to distinguish between
the two. (The terms are negotiable, but I think distinguishing between these
two concepts will help us).
well done.
I think of the class as Font because it
contains specific information about the typeface at a specific point size.
The layout engine passes the triplet to a Font method called, say,
provideFont. provideFont looks up the typeface in the list in Session. If
there, it returns it. If not, it attempts to create one. It then updates the
Document object or RenderingInstance object (probably the latter), with the
new /typeface/, so that it can later be embedded. As metric information is
needed by layout, it is gotten from this same Font class, which has hidden
all of the details of getting the FontMetric information, and simply passes
the size of the specific character back. Layout doesn't need to see anything
about FontMetrics except the end results that it needs to lay a line out
properly. In other words, if only two points of contact are needed, I prefer
to limit the contact to that.
Do I get you right that you would get something like that?
public interface Font {
String getFontName();
int getFontWeight();
int getFontSize();
FontMetrics getFontMetricsForLayout();
}
public interface FontMetrics {
//These methods already take font size into account
int getAscender();
int getDescender();
int getCapHeight();
//more...
int getWidth(char c);
boolean hasKerningAvailable();
//more...
}
That looks promising.
No statics please. We'll use an interface for lookup. The interface will
be provided (IoC) to the objects that need font lookup (through Avalon's
ServiceManager for example).
That is fine. If they are not statics, then they need to be in a singleton,
which is the Session concept. At the least, it seems good to have a static
pointer to the singleton so that you don't have to pass the singleton object
reference around everywhere you go. Maybe I am missing something here, and I
don't know how anything about ServiceManager.
We'll see about that. I think first we have to define some interfaces
and we can handle the implementation specifics later.
The classic Singleton pattern implementation (using statics) usually
isn't used when working in an Avalon environment. You almost never use
static stuff except for constants. But there are ways to mimic the
singleton pattern.
You'll see that I have a two-step font lookup in mind.
Re: thoughts on fonts (was: text-decoration)
properly discuss things like Session, Document, Rendering run, FOP instances etc. Where to cache what? What objects/services hold/provide In my mind Document and Rendering run (as defined in the glossary) are probably the same thing (??). I added something called Rendering instance to distinguish between different output media for the same document. Feel free to choose different terms -- I throw those out only to draw the distinction. That's good. I wonder what the others think about this terminology, because IMO this affects the whole redesign. If I understand it correctly we could have: - multiple output targets for one rendering run - targets with the same font metrics can layout to a common area tree - targets with similar or substitute metrics could force layout to one area tree - other targets can have different area trees from the same fo tree Would a rendering context make sense, which is created for each rendering instance and used to determine what to do for layout, rendering. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: thoughts on fonts (was: text-decoration)
Hi Keiron If I understand it correctly we could have: - multiple output targets for one rendering run - targets with the same font metrics can layout to a common area tree - targets with similar or substitute metrics could force layout to one area tree - other targets can have different area trees from the same fo tree Yep, though as Victor said, it remains to be seen if we will implement every feature from the beginning. It could be a lot of work. But I'd like to write down every idea so we have a reference for future work. Would a rendering context make sense, which is created for each rendering instance and used to determine what to do for layout, rendering. Yes, we need something like that. That's what's next on my todo list right after finishing the first version of the tutorial. But if one of you wants to start already please add a new Wiki page and add your thoughts. In short, that page should describe the following: - We've got various information holders/sources. We need to list them and place them in the architecture. Some information is hold over multiple rendering instances, some is only hold for one. - Putting FOUserAgent in the right context. It's something rather static though we will want the ability to have multiple instances per VM. This is configurable by config file and by subclassing. - the rendering context you just mentioned. Is this the right name for this? What information will it hold? etc. - We've got various caches. Where will we place each one? - How Avalon and the future API(s) will play into this. - add your ideas... Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: thoughts on fonts (was: text-decoration)
I've added my current thoughts to a Wiki page for those interested in this discussion: http://nagoya.apache.org/wiki/apachewiki.cgi?FOPFontSubsystemDesign You're all welcome to participate. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: thoughts on fonts (was: text-decoration)
Jeremias Maerki wrote: A Wiki is probably easier to work with in this case. CVS update, edit, CVS commit, Website update is a lot of work. I'll start a Wiki page and add my thoughts to it. We can always transfer the contents back to XML later. Good. I don't think I knew what a wiki was when I wrote this page. Thanks for transferring it over. During the refactoring I've made FontDescriptor extend from FontMetric. That was a natural thing to do at that point. Thinking about this some more, I don't think that was a wise move. From an SoC (Separation of Concerns) point of view this is bad, because I mix the concerns information for layout (ex. Ascender depending on the font size) and information for output formats (ex. Ascender for standard font size). It's probably best to break off a common anscestor interface (probably containing on two methods: getFontName() and getFontType()). FontMetrics und FontDescriptor will then extend from that common interface. A font implementation may implement one or both interfaces. AWT output will probably only implement FontMetrics. Let me say up front that I am going to follow your lead here. However, from a design standpoint, the interface between Font stuff and the rest of FOP seems really simple -- 1) layout needs a method that it passes font descriptions to, and that it gets a Font object back; 3) layout needs font metric information; 3) the renderers need a list of fonts that need to be embedded. /Everything/ else can be hidden, including FontMetrics. Also, all of the differences between font types can be hidden behind this same facade. information for purposes of embedding listing at render time. The /Document/ object needs to get passed almost everywhere, but at least all Is that sentence finished? Anyway... Only in my mind -- sorry. What I meant to say is that if we have a Document object that we put this information into, yes, we have to pass it around, but we can put other non-Font stuff into it as well. I don't like FontInfo. I want that to be an interface. Last night, I've come up with a few ideas that I'm going to add to the Wiki page. There's more and more Avalon that should be taken into account. I'm slowly starting to understand how Avalon can be used within FOP. Avalon is one area that I need to get up to speed on. The other is (and someone mentioned this several weeks ago), how Batik uses fonts, and to see whether we can share/use some of their work. With regard to FontInfo being an interface, I thought the data in it simply became part of the Session and Document concepts. I think the FontMetrics should eventually be seen only by the Font object. However, it might need to be a Facade itself to deal with the different ways font metric information can be returned. No, I think it's the other way around. FontMetrics should only be seen by the layout engine. I don't even know what a Font object will be. We'll have to define what a Font object is, if something like that will ever exist. The Font object for me is just an implementation of a font. Nothing that will be used directly, at least by the layout engine, well, probably by the output handlers that need to access a myriad of values for font registration. OK, I have not made myself clear. First, see the wiki glossary, where I have added definitions for font and typeface to try to distinguish between the two. (The terms are negotiable, but I think distinguishing between these two concepts will help us). I think of the class as Font because it contains specific information about the typeface at a specific point size. The layout engine passes the triplet to a Font method called, say, provideFont. provideFont looks up the typeface in the list in Session. If there, it returns it. If not, it attempts to create one. It then updates the Document object or RenderingInstance object (probably the latter), with the new /typeface/, so that it can later be embedded. As metric information is needed by layout, it is gotten from this same Font class, which has hidden all of the details of getting the FontMetric information, and simply passes the size of the specific character back. Layout doesn't need to see anything about FontMetrics except the end results that it needs to lay a line out properly. In other words, if only two points of contact are needed, I prefer to limit the contact to that. No statics please. We'll use an interface for lookup. The interface will be provided (IoC) to the objects that need font lookup (through Avalon's ServiceManager for example). That is fine. If they are not statics, then they need to be in a singleton, which is the Session concept. At the least, it seems good to have a static pointer to the singleton so that you don't have to pass the singleton object reference around everywhere you go. Maybe I am missing something here, and I don't know how anything about ServiceManager. You'll see that I have a two-step font lookup in
Re: text-decoration
Hi Oleg Wait a minute! I'm just about to commit a huge bunch of changes which includes TextInfo/FontState stuff. Not that I changed a lot. I've just got rid of stuff that wasn't used and I don't want you to have to change a lot again after my commit. On your question, I can't answer right away, but it is one one the things that got my attention when going over these classes. I'll dig deeper into this as soon as the CVS commits are done. More to come... On 08.01.2003 13:11:34 Oleg Tkachenko wrote: How are we going to process underline/overline etc stuff? It's a little bit confusing - we've got unused TextState class along with TextInfo that includes text-decoration info already. Lets get rid of TextState ? And what about rendering, does pdf support text-decoration directly or we have to draw lines as in the branch? Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: text-decoration
Jeremias Maerki wrote: Wait a minute! I'm just about to commit a huge bunch of changes which includes TextInfo/FontState stuff. Not that I changed a lot. I've just got rid of stuff that wasn't used and I don't want you to have to change a lot again after my commit. That's fine. -- Oleg Tkachenko eXperanto team Multiconn Technologies, Israel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: text-decoration
Hello! How are we going to process underline/overline etc stuff? It's a little bit confusing - we've got unused TextState class along with TextInfo that includes text-decoration info already. Lets get rid of TextState ? And what about rendering, does pdf support text-decoration directly or we have to draw lines as in the branch? For the area tree and rending these traits, I think, can apply to inline area, inline parent or line area. For the pdf renderer I think it needs to be a line drawn as in the branch as pdf doesn't support it. One problem would be that the underline should be constant across all the text and whitespace, if pdf supported it then it would not work properly anyway. Have you managed to work out how the underline/overline should work, for example when there are embedded inline areas that contain a different font, colour or baseline. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: text-decoration
Hi Oleg On 08.01.2003 13:11:34 Oleg Tkachenko wrote: How are we going to process underline/overline etc stuff? It's a little bit confusing - we've got unused TextState class along with TextInfo that includes text-decoration info already. Lets get rid of TextState ? And what about rendering, does pdf support text-decoration directly or we have to draw lines as in the branch? TextState seems to be dead. References in PageNumber, PageNumberCitation and FOText but without any function. So remove it. TextInfo looks better but could IMO be merged with FontState which only hold the font name and size and a link to the FontMetrics. Anyway, I think this merged class will be a candidate for the Flyweight pattern so we don't generate so many TextInfo/FontState objects (one for each FObj I think). Brings up the question of efficiently looking up existing Flyweights, on the other side. As far as underline/overline stuff is concerned, I like the idea of having PrintRenderer calculate these and calling subclasses to draw the lines (like in the branch). That makes the behaviour uniform over most renderers (those derived from PrintRenderer). Would it help if I started again with the PostScript renderer so code factored out into PrintRenderer can be verified? Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: text-decoration
Jeremias Maerki wrote: TextInfo looks better but could IMO be merged with FontState which only hold the font name and size and a link to the FontMetrics. Anyway, I think this merged class will be a candidate for the Flyweight pattern so we don't generate so many TextInfo/FontState objects (one for each FObj I think). Brings up the question of efficiently looking up existing Flyweights, on the other side. I also saw elements of the Facade pattern here on the font stuff. I documented some of these thoughts at http://xml.apache.org/fop/dev/fonts.html. I suppose a wiki would have been better that is pretty much how I viewed this page -- the point is to feel free to hack away at that document if you wish. It looks like you have started some of the moving and consolidating work that needed to be done with the scattered classes. I thought that most of the surviving font-related classes should be private used only by a Font class that was a Facade for all of the underlying types of fonts, including (eventually) AWT fonts seen by any existing graphical environment. I was all set to put the FontInfo into static variables so that it didn't have to be passed around so much. I see that multiple threads make that a bad idea. What we need (and probably already have -- I haven't had time to look) is the equivalent of a Document class that the FontInfo lists can be put into. Thus, our Font, Typeface, and TypefaceFamily classes apply to an FOP Session, but the /Document/ object keeps a list of at least Typeface information for purposes of embedding listing at render time. The /Document/ object needs to get passed almost everywhere, but at least all I think the FontMetrics should eventually be seen only by the Font object. However, it might need to be a Facade itself to deal with the different ways font metric information can be returned. To get the Flyweight working, when a Font resource is requested during layout, we have to look in the tables of pre-existing objects (this should be static), and either return an existing one or create a new one, then also update the /Document/ info. Something like FontState or TextState (one or the other) is probably good to keep pointers to all of this stuff (including Font) in one place. However, since the other items are basically (I think) boolean in nature (underline on or off), maybe it is just as good to simply pass the area object around which should have all of this stuff. One of the bad smells was the amount of information that had to be passed to get anything done. I don't know how this matches up with where you are going, but I thought I ought to throw it out there FWIW. You are probably way ahead of me on all of this. Also, I thought that a discussion of how Session stuff is separated from Document stuff for multithreading might be worthwhile. It will probably be a couple of weeks before I can get back into this much. Sorry to be on the sidelines for a bit. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 5655] - text-decoration cannot take multiple values
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5655. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5655 text-decoration cannot take multiple values [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |ASSIGNED --- Additional Comments From [EMAIL PROTECTED] 2002-11-13 23:24 --- I'd call it a unimplemented feature ;-) It will be implemented sometime but has a low priority. A possible workaround: fo:inline text-decoration=underline This is a workaround for fo:inline text-decoration=overline the combination ofdifferent text-decoration values... /fo:inline/fo:inline - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 1923] - text-decoration does not work
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1923. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1923 text-decoration does not work [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-11-11 23:50 --- If there is still a problem please reopen the bug and attach a sample - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[Fwd: text-shadow and text-decoration]
The editors, 7.16.5 text-shadow has offsets defined in terms of horizontal distance to the right and vertical distance below the text. The section also specifies: Inherited: no, see prose There is no mention of inheritance in the prose of section 7.16.5. 7.16.4 text-decoration, likewise, has: Inherited: no, see prose It does discuss inheritance. This property describes decorations that are added to the text of an element. If the property is specified for a block-level element, it affects all inline-level descendants of the element. If it is specified for (or affects) an inline-level element, it affects all boxes generated by the element. If the element has no content or no text content (e.g., the IMG element in HTML), user agents must ignore this property. This is confusing because it seems to imply that the property *is* inherited. Also, if the last sentence quoted is taken to mean, if the element has no text content user agents must ignore this property, how is this property to affect specified fo:character elements within its ambit? Is it the intention that the property apply to all implicit and explicit fo:character elements descended from the element on which it is defined? Is the complication here to do with the handling of inline-progression spacing? Peter West - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 4492] - text-decoration=underline on fo:block ignored
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4492. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4492 text-decoration=underline on fo:block ignored [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-02-08 18:29 --- Done, see 0.20.3RC - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [PATCH] text-decoration for blocks (maintenance branch)
Tore Engvig wrote: Christian Geisert wrote: Hi, this patch adds text-decoration support for blocks. There still some things I want to do (like inherit text-decoration from a parent inline, problems with hyphenation and nbsp). Actually I think fop supports nbsp (more or less). Also nonbreaking nbsp and some other space variants (check layout/LineArea) I meant those problems in context with text-decoration (yes, the text was a bit misleading ;-) like: fo:inline text-decoration=underline#160;#160;#160;#160;/fo:inline Tore Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[PATCH] text-decoration for blocks (maintenance branch)
Hi,
this patch adds text-decoration support for blocks. There still some things
I want to do (like inherit text-decoration from a parent inline, problems with
hyphenation and nbsp).
Christian
Index: docs/examples/fo/textdeko.fo
===
RCS file: /home/cvspublic/xml-fop/docs/examples/fo/textdeko.fo,v
retrieving revision 1.3.4.1
diff -u -u -r1.3.4.1 textdeko.fo
--- docs/examples/fo/textdeko.fo2001/12/06 21:28:18 1.3.4.1
+++ docs/examples/fo/textdeko.fo2001/12/11 19:36:36
@@ -77,7 +77,7 @@
line-height=15pt
space-after.optimum=10pt
text-align=start
-This is simple test of the text-decorationfo:inline
text-decoration=underlineunderline/fo:inline.
+This is simple test of the text-decoration fo:inline
+text-decoration=underline'underline'/fo:inline.
/fo:block
fo:block font-size=22pt
font-family=sans-serif
@@ -96,7 +96,7 @@
/fo:block
fo:block font-size=12pt font-family=sans-serif line-height=15pt
text-align=justify space-after.optimum=3pt
- The following text decorations are defined in the CR:
+ The following text decorations are defined in the REC:
/fo:block
fo:list-block space-after.optimum=13pt
@@ -244,6 +244,12 @@
space-after.optimum=10pt
text-align=start
What about underlining of whitespace onlyfo:inline
text-decoration=underline /fo:inline?
+ /fo:block
+
+
+ fo:block space-after.optimum=13pt font-size=14pt
+text-decoration=underline
+ A whole block should work now.
+ And again some more Text to get at least two lines.
/fo:block
Index: src/org/apache/fop/fo/FObjMixed.java
===
RCS file: /home/cvspublic/xml-fop/src/org/apache/fop/fo/FObjMixed.java,v
retrieving revision 1.12
diff -u -u -r1.12 FObjMixed.java
--- src/org/apache/fop/fo/FObjMixed.java2001/08/01 22:12:52 1.12
+++ src/org/apache/fop/fo/FObjMixed.java2001/12/11 19:36:45
@@ -8,6 +8,7 @@
package org.apache.fop.fo;
import org.apache.fop.layout.Area;
+import org.apache.fop.layout.TextState;
import org.apache.fop.apps.FOPException;
/**
@@ -16,6 +17,9 @@
*/
public class FObjMixed extends FObj {
+// Textdecoration
+protected TextState ts;
+
public static class Maker extends FObj.Maker {
public FObj make(FObj parent,
PropertyList propertyList) throws FOPException {
@@ -33,7 +37,14 @@
}
protected void addCharacters(char data[], int start, int length) {
-addChild(new FOText(data, start, length, this));
+// addChild(new FOText(data, start, length, this));
+FOText ft = new FOText(data, start, length, this);
+ft.setLogger(log);
+ft.setUnderlined(ts.getUnderlined());
+ft.setOverlined(ts.getOverlined());
+ft.setLineThrough(ts.getLineThrough());
+addChild(ft);
+
}
public Status layout(Area area) throws FOPException {
Index: src/org/apache/fop/fo/PropertyManager.java
===
RCS file: /home/cvspublic/xml-fop/src/org/apache/fop/fo/PropertyManager.java,v
retrieving revision 1.7
diff -u -u -r1.7 PropertyManager.java
--- src/org/apache/fop/fo/PropertyManager.java 2001/08/06 09:12:58 1.7
+++ src/org/apache/fop/fo/PropertyManager.java 2001/12/11 19:36:47
@@ -26,6 +26,8 @@
import java.text.FieldPosition;
import org.apache.fop.layout.Area;
import org.apache.fop.layout.ColumnArea;
+import org.apache.fop.layout.TextState;
+import org.apache.fop.fo.properties.TextDecoration;
public class PropertyManager {
@@ -247,4 +249,29 @@
AbsolutePositionProps props = new AbsolutePositionProps();
return props;
}
+
+public TextState getTextDecoration() throws FOPException {
+TextState ts = new TextState();
+
+int textDecoration = this.properties.get(text-decoration).getEnum();
+
+switch (textDecoration) {
+case TextDecoration.UNDERLINE:
+ts.setUnderlined(true);
+break;
+case TextDecoration.OVERLINE:
+ts.setOverlined(true);
+break;
+case TextDecoration.LINE_THROUGH:
+ts.setLineThrough(true);
+break;
+case TextDecoration.NONE:
+ts.setUnderlined(false);
+ts.setOverlined(false);
+ts.setLineThrough(false);
+}
+
+return ts;
+}
+
}
Index: src/org/apache/fop/fo/flow/Block.java
===
RCS file: /home/cvspublic/xml-fop/src/org/apache/fop/fo/flow/Block.java,v
retrieving revision 1.41.2.1
diff -u -u -r1.41.2.1 Block.java
--- src/org/apache/fop/fo/flow/Block.java 2001/12/06 21:28:21 1.41.2.1
+++ src/org/apache/fop/fo/flow
DO NOT REPLY [Bug 4492] - text-decoration=underline on fo:block ignored
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4492. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4492 text-decoration=underline on fo:block ignored --- Additional Comments From [EMAIL PROTECTED] 2001-11-28 05:04 --- Christian Geisert [EMAIL PROTECTED] sent this to fop-dev: But to underline one must use fo:inline, right?? At the moment: yes! I have started coding support for underline in blocks some time ago, but it's not finished yet Christian, can you update this bug when you make some progress? Thanks! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 4492] New: - text-decoration=underline on fo:block ignored
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4492. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4492 text-decoration=underline on fo:block ignored Summary: text-decoration=underline on fo:block ignored Product: Fop Version: 0.15 Platform: Sun OS/Version: Solaris Status: NEW Severity: Minor Priority: Other Component: general AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] If I set text-decoration=underline on an fo:block it is ignored; if I set it on an inline it works. The XSL 1.0 spec says text-decoration applies to all elements. It also says If the property is specified for a block-level element, it affects all inline-level descendants of the element. Am I missing something, or is FOP getting it wrong? (If I'm misunderstanding it, please explain why - thanks!) Here's an example: ?xml version=1.0 encoding=UTF-8? fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format; fo:layout-master-set fo:simple-page-master margin-right=25mm margin-left=25mm margin-bottom=20mm margin-top=15mm page-height=297mm page-width=210mm master-name=a4 fo:region-before extent=10mm/ fo:region-after extent=10mm/ fo:region-body margin-bottom=15mm margin-top=15mm/ /fo:simple-page-master /fo:layout-master-set fo:page-sequence master-name=a4 fo:flow flow-name=xsl-region-body fo:block fo:inline text-decoration=underline This will be underlined because the text-decoration is set on the inline element. /fo:inline /fo:block fo:block text-decoration=underline This will not be underlined even though a text-decoration is set on the block element. It also fails when text-decoration is set on basic-link elements. /fo:block /fo:flow /fo:page-sequence /fo:root This is with version 0.20.2-RC (can someone update the list of versions in Bugzilla - it only goes as far as 0.17!). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Text Decoration
Title: Message It appears as if between .12 and the current cvs the last parameter for fontstate which was textdecoration in .12 is now only supporting text-variant and the text-decoration is lost as it is not passed through. Was this picked up somewhere else and I'm missing it ? John John H. Wyman5160 Darry LaneDublin, OH 43016(614)-889-0698[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]Wyman Genealogy Site http://www.wyman.orgFrancis Wyman Assoc email List http://groups.yahoo.com/group/FrancisWymanAssocWyman Family Genealogy Forum http://genforum.genealogy.com/wyman/The Wyman Surname Message Board http://www.familyhistory.com/messages/messages.asp?category=surnameforum=Wyman
Text-Decoration (underline) Problem
Title: Message This used to work in .12 doesn't work in ,18 and up, I think it should, could someone look into it, please. Underline isn't done and I can't move the underline inside of the Table Cell because of the way the document is generated. The table is used only for output to add line numbers. fo:block break-before="auto" space-before.optimum="12pt"fo:inline text-decoration="underline"fo:tablefo:table-column column-width="155.708mm" column-number="1"/fo:table-column column-width="2.324mm" column-number="2"/fo:table-column column-width="16.268mm" column-number="3"/fo:table-bodyfo:table-rowfo:table-cell column-number="1"fo:block start-indent="0.2324mm" text-indent="11.62mm" space-before.optimum="6pt" text-align="start" font-weight="normal" font-size="11pt" font-family="Courier"fo:inline font-weight="bold"Section 1. /fo:inline That section 4935.03 of the Revised Code be amended to read as follows:/fo:block/fo:table-cellfo:table-cell column-number="2"/fo:table-cell column-number="3"/fo:table-cell/fo:table-row/fo:table-body/fo:table/fo:inline/fo:block John H. Wyman5160 Darry LaneDublin, OH 43016(614)-889-0698[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]Wyman Genealogy Site http://www.wyman.orgFrancis Wyman Assoc email List http://groups.yahoo.com/group/FrancisWymanAssocWyman Family Genealogy Forum http://genforum.genealogy.com/wyman/The Wyman Surname Message Board http://www.familyhistory.com/messages/messages.asp?category=surnameforum=Wyman
Re: Text-Decoration (underline) Problem
John Wyman wrote: This used to work in .12 doesn't work in ,18 and up, I think it should, could someone look into it, please. I'm quite sure it did not work in 0.12 !! (And as I have done the code for text-decoration I should know ;-) Underline isn't done and I can't move the underline inside of the Table Cell because of the way the document is generated. The table is used only for output to add line numbers. My first thought was that this is not legal XSL but after looking at the CR I'm not sure anymore: If the property is specified for a block-level element, it affects all inline-level descendants of the element. If it is specified for (or affects) an inline-level element, it affects all boxes generated by the element. As it is specified for a inline-level element the question is if the table is a box generated by this elemnet ? Anyway, it is is not implemented yet and I don't know when/if I get some time to do it.. fo:block break-before=auto space-before.optimum=12pt fo:inline text-decoration=underline fo:table [...] John H. Wyman Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
