[RTF] jfor progress

[Victor Mote <vi...@outfitr.com>]

Bertrand et al:

I've been hacking away at the RTFLib/jfor stuff a bit. Except for TODO
items, the checkstyle stuff is complete. Also, I have written the beginnings
of the API doc, the latest version of which can be seen here:
http://forrestbot.cocoondev.org/sites/xml-fop/dev/rtflib.html
I have tried to highlight the independence of the package.

Question for Everyone:
I *really* like the approach of having the independent package, and
recommend that we use the same approach for other StructureRenderers,
including MIF, and the yet-unborn merely-glimmers-in-my-mind RawText and TeX
renderers. Any comments?

Questions (mostly for Bertrand):

1. How much does the API need to be protected? Are we pretty free to change
it as we see fit, or will that mess up existing jfor users too much? I'm
going to try to keep the doc up-to-date as we go, so that might mitigate a
lot of the pain of changes. Specifically, I am tempted to move some of the
constants (alignment and indentation for example) in RtfText to RtfParagraph
for a more intuitive interface. That is clearly not important to do now, but
some of the others below might be, so I thought it good to ask the question
now.

2. It looks like the border stuff gets ugly quickly, because of all of the
axes that it works on (which side, design, color, thickness, seems like
several others). Rather than trying to build 2**n boolean concepts (where n
is the sum of all of the possibilities on each axis -- just think about
color, for example), what do you think of the idea of building a Border
object with those axes as properties, then pointing to that object (or
better yet, an integer reference to it, ala ColorTable and the font table)
in the regular Attributes logic? That probably makes like easier on a user
as well as us. I'm guessing there are some other concepts that will benefit
from such an approach as well.

3. I so far have only made one substantive change: I have changed
RtfParagraph.writeRtfPrefix() to write the text attributes as well as the
paragraph attribute. It seemed to me that if the user wants to set those at
the paragraph level, it is good to be able to do so. They can still set them
at the Text level if they wish. However, I may be missing something here.

Victor Mote


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

Re: [RTF] jfor progress

[Glen Mazza <gr...@yahoo.com>]

--- Glen Mazza <gr...@yahoo.com> wrote:
> --- Victor Mote <vi...@outfitr.com> wrote:
> > Question for Everyone:
> > I *really* like the approach of having the
> > independent package, and
> > recommend that we use the same approach for other
> > StructureRenderers,
> > including MIF, and the yet-unborn
> > merely-glimmers-in-my-mind RawText and TeX
> > renderers. Any comments?
> > 
> 
> Sounds good, but to help me better understand, in
> the
> document you wrote:
> 
> <Q>
> It does not require FOP as a front-end, nor does it
> even require XSL-FO for input. 
> </Q>
> 
> Precisely, what does it require for input?  Will it
> accept XSL-FO for input?  I would put in a sentence
> or
> two explaining what its input is.
> 
> Glen
> 

Restating, I realize it does not contain its own XSLFO
processor, but a short statement at the beginning (in
addition to your detailed summary later on) of what it
*is* fed may help emphasize the black box nature
(i.e., what you're trying to highlight) of this
independent package.

Glen


__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

Re: [RTF] jfor progress

[Glen Mazza <gr...@yahoo.com>]

--- Victor Mote <vi...@outfitr.com> wrote:
> Question for Everyone:
> I *really* like the approach of having the
> independent package, and
> recommend that we use the same approach for other
> StructureRenderers,
> including MIF, and the yet-unborn
> merely-glimmers-in-my-mind RawText and TeX
> renderers. Any comments?
> 

Sounds good, but to help me better understand, in the
document you wrote:

<Q>
It does not require FOP as a front-end, nor does it
even require XSL-FO for input. 
</Q>

Precisely, what does it require for input?  Will it
accept XSL-FO for input?  I would put in a sentence or
two explaining what its input is.

Glen


__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

RE: [RTF] jfor progress

[Victor Mote <vi...@outfitr.com>]

Bertrand Delacretaz wrote:

> Maybe a new build target that creates a standalone fop-rtflib.jar would
> be good?
> I'd still keep rtflib in the main fop.jar, but offer a standalone
> rtflib in addition.

+1

> Note that the interest for a MIF renderer is probably lower than it was
> before, as newer versions of FrameMaker can import XML directly and
> combine it with (homegrown) style mappings.

Good point. However, I know that I have some interest in it, because of the
ability to use XSLT for the style mappings instead of Frame. To make this
work, we need (and probably need anyway, and can probably expect to see in a
future FO standard) the ability to create styles in FO. I may propose such
an extension in the future, but I'll probably defer it as long as possible
in the hopes that the FO standard will get there first.

BTW, I have a big beef with Adobe (FrameMaker) and Corel (WordPerfect) for
claiming that their products support XML, when they use proprietary
character sets, and have *no* way to deal with Unicode.

> An alternative would be to define constants in interfaces
> (RtfAlignConstants, RtfParaConstants etc) to group them, and have the
> classes that use them implement these interfaces to make the values
> directly available. This would be more compatible with the existing API
> I think.

Good idea. I'll think on this a bit.

> > ...have changed
> > RtfParagraph.writeRtfPrefix() to write the text attributes as well as
> > the
> > paragraph attribute....
>
> If one can still set text attributes on individual text runs inside a
> paragraph as well, then fine.

Yes.

> I'm not happy with the current design of RtfText embedded in
> RtfParagraph - although this maps well to the XSL-FO model
> ("elements"), it does not map well to the RTF model ("text runs" I
> think, but still somewhat mysterious after all these years ;-).
> This causes problem in jfor where nested paragraphs and inlines are
> sometimes output in the wrong order. I think a "flatter" design of the
> RtfText vs. RtfParagraph model would help.

Yes, I ran into this in what I thought would be a trivial exercise of adding
background colors to paragraphs. If you set the color at the beginning of
the paragraph, it affects the rest of the document. My tentative solution
was to simply keep track of the "state" of the concept on the FOP side, and
look for changes. However, I expect that we can throw more of this burden
onto the RTFLib side, perhaps with a configurable option that could either
favor an element-driven approach or a text-run-driven approach. The \par vs.
\pard might help in this regard.

It sounds like we are on the same page so far. Please let me know if you see
me heading off in a bad direction.

Victor Mote


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

Re: [RTF] jfor progress

[Bertrand Delacretaz <bd...@codeconsult.ch>]

Hi Victor,

Thanks for your work!

> ...I *really* like the approach of having the independent package, and
> recommend that we use the same approach for other StructureRenderers,
> including MIF....

Yes, the StructureRenderer interface nicely decouples these renderers 
from the rest of FOP.

Maybe a new build target that creates a standalone fop-rtflib.jar would 
be good?
I'd still keep rtflib in the main fop.jar, but offer a standalone 
rtflib in addition.

Note that the interest for a MIF renderer is probably lower than it was 
before, as newer versions of FrameMaker can import XML directly and 
combine it with (homegrown) style mappings.

> ...1. How much does the API need to be protected? Are we pretty free 
> to change
> it as we see fit, or will that mess up existing jfor users too much? 
> ...

It is hard to say, although there have been several thousand downloads 
of jfor since it was created, the feedback from users is comparatively 
very small so we don't have a precise idea of how many people are doing 
what.

I know some people are using the RTF API directly, but have no idea how 
many.

I think you can go ahead with API changes that improve the library or 
are required for refactoring (see below comments about RtfText).

> ...Specifically, I am tempted to move some of the
> constants (alignment and indentation for example) in RtfText to 
> RtfParagraph
> for a more intuitive interface....

Makes sense.

An alternative would be to define constants in interfaces 
(RtfAlignConstants, RtfParaConstants etc) to group them, and have the 
classes that use them implement these interfaces to make the values 
directly available. This would be more compatible with the existing API 
I think.

> ...what do you think of the idea of building a Border
> object with those axes as properties...

Sounds good.
IIRC this border stuff has been contributed in small bits and pieces to 
jfor, with no real design, so some refactoring is welcome.

> ...I'm guessing there are some other concepts that will benefit
> from such an approach as well....

Yes, you've probably seen code that is too "linear" and could benefit 
from better object design.

> ...have changed
> RtfParagraph.writeRtfPrefix() to write the text attributes as well as 
> the
> paragraph attribute....

If one can still set text attributes on individual text runs inside a 
paragraph as well, then fine.

I'm not happy with the current design of RtfText embedded in 
RtfParagraph - although this maps well to the XSL-FO model 
("elements"), it does not map well to the RTF model ("text runs" I 
think, but still somewhat mysterious after all these years ;-).
This causes problem in jfor where nested paragraphs and inlines are 
sometimes output in the wrong order. I think a "flatter" design of the 
RtfText vs. RtfParagraph model would help.

-Bertrand


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org