text-decoration

[Peter B. West]

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

[Glen Mazza]

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
> 
> 

Re: Implementing text-decoration

[Peter B. West]

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

RE: Implementing text-decoration

[Victor Mote]

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

Implementing text-decoration

[Jeremias Maerki]

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

DO NOT REPLY [Bug 25275] New: - fo:page-number ignores text-decoration="underline" attribute

[bugzilla]

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:


  9pt
  underline


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):



 - 

  
  
  

  


I've tried modifying the page-number call as follows:


And:


And:
  
  

 - 

  
  
  

  


And:
  
  

 - 

  
  
  
    
  


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)

[Peter B. West]

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)

[Jeremias Maerki]

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)

[Jeremias Maerki]

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)

[Victor Mote]

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)

[Peter B. West]

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: text-decoration

[Oleg Tkachenko]

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]

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: thoughts on fonts (was: text-decoration)

[Jeremias Maerki]

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)

[Keiron Liddle]

> > > 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)

[Jeremias Maerki]

Hi Victor

On 09.01.2003 19:09:17 Victor Mote wrote:

> 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 mim

RE: thoughts on fonts (was: text-decoration)

[Victor Mote]

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

Re: thoughts on fonts (was: text-decoration)

[Jeremias Maerki]

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]

Hi Victor

Good that you spoke up, so we can discuss this.

On 08.01.2003 19:31:35 Victor Mote wrote:
> 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.

Have seen that now for the first time. I shall check the design docs
more frequently in the future. :-)

> 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.

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.

> It looks like you have
> started some of the moving and consolidating work that needed to be done
> with the scattered classes.

Yep, it also helped me understand a lot more about its "design". It has
grown too much over time.

> 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 see it this way:
As you already figured out there are several aspects to the font
subsystem:
- Provide information (font metrics -> FontMetrics) for the layout
  process
- Provide information (more detailed font metrics, pointers to font
  files -> FontDescriptor) for the various output format handlers. I
  don't say "renderers" here because the PDF library is actually the
  recipient of the font information.
- Management of various font sources (file-based, AWT...)
- Management of the fonts actually used during a rendering run.
- Parsing of font files

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.

> 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

Is that sentence finished? Anyway...

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.

> 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.

> 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.

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).

You'll see that I have

RE: text-decoration

[Victor Mote]

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]

Re: text-decoration

[Jeremias Maerki]

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

[Keiron Liddle]

> 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

[Oleg Tkachenko]

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

[Jeremias Maerki]

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]

text-decoration

[Oleg Tkachenko]

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?
--
Oleg Tkachenko
eXperanto team
Multiconn Technologies, Israel


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

DO NOT REPLY [Bug 5655] - text-decoration cannot take multiple values

[bugzilla]

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:

 This is a workaround for 

the combination ofdifferent text-decoration values...


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

DO NOT REPLY [Bug 1923] - text-decoration does not work

[bugzilla]

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]

DO NOT REPLY [Bug 1923] - text-decoration does not work

[bugzilla]

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

   Priority||High



--- Additional Comments From [EMAIL PROTECTED]  2002-04-22 15:59 ---
The text-decoration="underline" does almost always work in FOP 0.20.3.
There are exceptions: a forward reference fo:page-number-citation will
not be underlined. Some spaces are not always underlined.
I'll leave this open.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

[Fwd: text-shadow and text-decoration]

[Peter B. West]

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

[bugzilla]

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]

[PATCH] more text-decoration (maintenance branch)

[Christian Geisert]

Ok,

this should be my last patch for this maintenance release ;-)

It adds inheritance for the text-decoration property from parent inline or
block elements and fixes a bug with non-breaking spaces (but not all)

Christian

Index: docs/examples/fo/textdeko.fo
===
RCS file: /home/cvspublic/xml-fop/docs/examples/fo/textdeko.fo,v
retrieving revision 1.3.4.2
diff -u -r1.3.4.2 textdeko.fo
--- docs/examples/fo/textdeko.fo13 Dec 2001 09:25:21 -  1.3.4.2
+++ docs/examples/fo/textdeko.fo9 Jan 2002 08:47:29 -
@@ -59,7 +59,7 @@
   
   The "text-decoration"-property describes decorations that are added to the text 
of an element.
   If the property is specified for a block-level element, it should affect all 
inline-level descendants
-  of the element (does not work yet!).
+  of the element.
   If it is specified for (or affects) an inline-level
   element, it affects all boxes generated by the element.
   
@@ -246,12 +246,38 @@
 What about underlining of whitespace only ?
   
 
-
   
   A whole block should work now.
-  And again some more Text to get at least two lines.
+  And again some more text to get at least two lines.
+  
+
+  
+
+  
+  
+  Let's see if all inline-areas are affected ...
+  
+  
+
   
 
+  
+  
+  This is a workaround for
+  
+  the combination of
+  different text-decoration values...
+  
+  
+  
+  
+
+  
+  Enter your name here:
+  _   
+   
+  
+ 
+  
 
 
   
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.2.1
diff -u -r1.12.2.1 FObjMixed.java
--- src/org/apache/fop/fo/FObjMixed.java13 Dec 2001 09:25:21 -  
1.12.2.1
+++ src/org/apache/fop/fo/FObjMixed.java9 Jan 2002 08:47:44 -
@@ -36,6 +36,10 @@
 super(parent, propertyList);
 }
 
+public TextState getTextState() {
+return ts;
+}
+
 protected void addCharacters(char data[], int start, int length) {
 // addChild(new FOText(data, start, length, this));
 FOText ft = new FOText(data, start, length, this);
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.2.1
diff -u -r1.7.2.1 PropertyManager.java
--- src/org/apache/fop/fo/PropertyManager.java  13 Dec 2001 09:25:22 -  1.7.2.1
+++ src/org/apache/fop/fo/PropertyManager.java  9 Jan 2002 08:47:46 -
@@ -250,24 +250,50 @@
 return props;
 }
 
-public TextState getTextDecoration() throws FOPException {
+public TextState getTextDecoration(FObj parent) throws FOPException {
+
+// TextState from parent Block/Inline
+TextState tsp = null;
+boolean found = false;
+
+do {
+String fname = parent.getName();
+if (fname.equals("fo:flow") || fname.equals("fo:static-content")) {
+found = true;
+} else if (fname.equals("fo:block") || fname.equals("fo:inline")) {
+FObjMixed fom = (FObjMixed) parent;
+tsp = fom.getTextState();
+found = true;
+}
+parent = parent.getParent();
+} while (!found);
+
 TextState ts = new TextState();
 
+if (tsp != null) {
+ts.setUnderlined(tsp.getUnderlined());
+ts.setOverlined(tsp.getOverlined());
+ts.setLineThrough(tsp.getLineThrough());
+}
+
 int textDecoration = this.properties.get("text-decoration").getEnum();
 
-switch (textDecoration) {
-case TextDecoration.UNDERLINE:
+if (textDecoration == TextDecoration.UNDERLINE) {
 ts.setUnderlined(true);
-break;
-case TextDecoration.OVERLINE:
+}
+if (textDecoration == TextDecoration.OVERLINE) {
 ts.setOverlined(true);
-break;
-case TextDecoration.LINE_THROUGH:
+}
+if (textDecoration == TextDecoration.LINE_THROUGH) {
 ts.setLineThrough(true);
-break;
-case TextDecoration.NONE:
+}
+if (textDecoration == TextDecoration.NO_UNDERLINE) {
 ts.setUnderlined(false);
+}
+if (textDecoration == TextDecoration.NO_OVERLINE) {
 ts.setOverlined(false);
+}
+if (textDecoration == TextDecoration.NO_LINE_THROUGH) {
 ts.setLineThrough(false);
 }
 
Index: src/org/apache/fop/fo/flow/Block.java

DO NOT REPLY [Bug 5655] New: - text-decoration cannot take multiple values

[bugzilla]

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

   Summary: text-decoration cannot take multiple values
   Product: Fop
   Version: all
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Normal
  Priority: Other
 Component: general
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Hi!

In fop (versions 0.20.1 & 0.20.2) it is not possible to assign more than one 
value to the attribute text-decoration.

Example:
The next sample can be found in textdeko.fo (in subdirectory 
fop/docs/examples/fo of the fop distribution).
Here, text-decoration="underline overline". But, when rendered with fop 
(version 0.20.2), I get the following error: "Unknown enumerated value for 
property 'text-decoration': underline overline"

Sample:

  Combination


Is this a bug?

Regards,
Joke Dehond

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: [PATCH] text-decoration for blocks (maintenance branch)

[Christian Geisert]

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  ).
> 
> Actually I think fop supports   (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:


> Tore

Christian

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: [PATCH] text-decoration for blocks (maintenance branch)

[Tore Engvig]

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  ).

Actually I think fop supports   (more or less). Also nonbreaking nbsp
and some other space variants (check layout/LineArea)


Tore


>
> Christian


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: [PATCH] text-decoration for blocks (maintenance branch)

[Keiron Liddle]

Hi,

I have submitted this patch to the branch.


On 2001.12.12 19:04 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  ).
> 
> Christian

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

[PATCH] text-decoration for blocks (maintenance branch)

[Christian Geisert]

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  ).

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-decorationunderline.
+    This is simple test of the text-decoration 'underline'.
   
   
 
   
-  The following text decorations are defined in the CR:
+  The following text decorations are defined in the REC:
   
 
   
@@ -244,6 +244,12 @@
 space-after.optimum="10pt"
 text-align="start">
 What about underlining of whitespace only ?
+  
+
+
+  
+  A whole block should work now.
+  And again some more Text to get at least two lines.
   
 
 
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/Block.java   2001/12/11 19:36:49
@@ -66,10 +66,13 @@
 // this may be helpful on other FOs too
 boolean anythingLaidOut = false;
 
-public Block(FObj parent, PropertyList propertyList) {
+public Block(FObj parent, PropertyList propertyList)
+throws FOPException {
+
 super(parent, propertyList);
 this.name = "fo:block";
 this.span = this.properties.

DO NOT REPLY [Bug 4492] - text-decoration="underline" on fo:block ignored

[bugzilla]

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

[bugzilla]

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:


http://www.w3.org/1999/XSL/Format";>
  

  
  
  

  
  


      
    
  This will be underlined because the text-decoration is set on the
  inline element.

  

  
    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.
  


  


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

[John Wyman]

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.org>Francis 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=surname&forum=Wyman>  

 

RE: Text-Decoration (underline) Problem

[John Wyman]

Christian,
I have a copy of .12 and it works just fine, and I verified it in .12
before posting the problem. I have been using it in production since
last year and uncovered this problem when I started converting to the
most current .19-cvs.

I'm perplexed by your comment that it couldn't have worked in .12 !

I'm kind of in a bind as we need some of the features in the current
version and this is the only outstanding item, can I twist your arm, or
if you can provide some pointers, I'll dig in myself. I'm becoming
entirely to intimate with the FOP code, might as well put it to some
use.

Regards
John


John H. Wyman
5160 Darry Lane
Dublin, OH 43016
(614)-889-0698
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
Wyman Genealogy Site <http://www.wyman.org>
Francis Wyman Assoc email List
http://groups.yahoo.com/group/FrancisWymanAssoc
Wyman Family Genealogy Forum <http://genforum.genealogy.com/wyman/>
The Wyman Surname Message Board
<http://www.familyhistory.com/messages/messages.asp?category=surname&for
um=Wyman>

  

-Original Message-
From: Christian Geisert [mailto:[EMAIL PROTECTED]] 
Sent: Tuesday, July 03, 2001 5:01 PM
To: [EMAIL PROTECTED]
Subject: 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..

>   text-decoration="underline"> 

[...]

> John H. Wyman

Christian

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Text-Decoration (underline) Problem

[Christian Geisert]

> 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..

> 
> 
> 

[...]

> John H. Wyman

Christian

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Text-Decoration (underline) Problem

[John Wyman]

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.
 
Section 1.  That section 4935.03 of 
the Revised Code be amended to read as 
follows:
 
John H. Wyman5160 Darry LaneDublin, OH 
43016(614)-889-0698[EMAIL PROTECTED] Wyman 
Genealogy Site Francis Wyman Assoc 
email List http://groups.yahoo.com/group/FrancisWymanAssocWyman 
Family Genealogy Forum The 
Wyman Surname Message Board   

 

Text-Decoration broken ?????

[John Wyman]

Title: Message



Hi,
I have code that 
again worked in .12 and may have worked in later versions, I can't find any 
documents to prove it, but now appears not to work in .19 and I'm in a real 
bind. Here is the section of the fo that doesn't work, the underline attribute 
doesn't work in this case. I compared the fo generated by my older version and 
the fo generated now and they are the same. It may have something to do with the 
fact that I'm printing inside of a table in-order to provide line numbering, but 
it did work before.
 
Please 
help.
John
 
John H. Wyman5160 Darry LaneDublin, OH 
43016(614)-889-0698[EMAIL PROTECTED] Wyman 
Genealogy Site Francis Wyman Assoc 
email List http://groups.yahoo.com/group/FrancisWymanAssocWyman 
Family Genealogy Forum The 
Wyman Surname Message Board   

 
 test1.fo

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: text-decoration in block

[Christian Geisert]

Hoang Nam wrote:
> 
> Hello all,
> 
> I have put the property text-decoration="underline" in block level and it
> did not work .
> It works only in inline object.
> 
> Could sombody tell me what I am doing wrong ? Could we have the property
> text-decoration in a block ? Or it is not implemented yet in block in FOP ?

>From the CR:
"If the property is specified for a block-level element, it affects all
inline-level descendants of the element."

So it should work but is not implemented yet. Text-decoration only works with
inline at the moment.

Workarround:


your text...



> Thanks alot !
> 
> Nam

Christian

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

text-decoration in block

[Hoang Nam]

Hello all,

I have put the property text-decoration="underline" in block level and it
did not work .
It works only in inline object.

Could sombody tell me what I am doing wrong ? Could we have the property
text-decoration in a block ? Or it is not implemented yet in block in FOP ?

Thanks alot !

Nam


_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]