headers
Nicola Ken Barozzi | 5 Sep 2002 09:42
Picon
Favicon

[PATCH] Add a "Patch queue" link on the website

This link queries Bugzilla to report all issues that begin with [PATCH].

http://nagoya.apache.org/bugzilla/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&email1=&emailtype1=substring&emailassigned_to1=1&email2=&emailtype2=substring&emailreporter2=1&bugidtype=include&bug_id=&changedin=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&product=Fop&short_desc=%5BPATCH%5D&short_desc_type=allwordssubstr&long_desc=&long_desc_type=allwordssubstr&bug_file_loc=&bug_file_loc_type=allwordssubstr&keywords=&keywords_type=anywords&field0-0-0=noop&type0-0-0=noop&value0-0-0=&cmdtype=doit&order=Reuse+same+sort+as+last+time

--

-- 
Nicola Ken Barozzi                   nicolaken <at> apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------
Permalink | Reply | 0 comments |
headers
Nicola Ken Barozzi | 5 Sep 2002 10:20
Picon
Favicon

Re: [FOP Avalonization] Status update + recent discussion on Avalon dev


Jeremias Maerki wrote:
> On 04.09.2002 14:26:14 Nicola Ken Barozzi wrote:
> 
>>Jeremias Maerki wrote:
>>
>>>On 04.09.2002 13:42:50 Nicola Ken Barozzi wrote:
>>>
>>>
>>>>Jeremias Maerki wrote:
>>>
>>...
>>
>>>>>What do you have in mind to use as container? I've started using
>>>>>Fortress yesterday for a little private project and I liked it very much.
>>>>>Much better than the ECM.
>>>>
>>>>I would not use a container at all ATM.
>>>
>>>That means you just concentrate on the top-level component? FOP insides
>>>at a later time?
>>
>>Yes.
>>Well, if we *ever* will want to apply Avalon to the insides.
> 
> But one of your goals is the use of Excalibur's SourceResolver which
> means you automatically start using Avalon in the insides.

Aha! :-D
(Continue reading)

Permalink | Reply | 4 comments |
headers
Jeremias Maerki | 5 Sep 2002 11:08
Picon
Favicon

Re: [FOP Avalonization] Status update + recent discussion on Avalon dev


On 05.09.2002 10:20:07 Nicola Ken Barozzi wrote:
> 
> Jeremias Maerki wrote:
> > On 04.09.2002 14:26:14 Nicola Ken Barozzi wrote:
> > 
> >>Jeremias Maerki wrote:
> >>
> >>>On 04.09.2002 13:42:50 Nicola Ken Barozzi wrote:
> >>>
> >>>
> >>>>Jeremias Maerki wrote:
> >>>
> >>...
> >>
> >>>>>What do you have in mind to use as container? I've started using
> >>>>>Fortress yesterday for a little private project and I liked it very much.
> >>>>>Much better than the ECM.
> >>>>
> >>>>I would not use a container at all ATM.
> >>>
> >>>That means you just concentrate on the top-level component? FOP insides
> >>>at a later time?
> >>
> >>Yes.
> >>Well, if we *ever* will want to apply Avalon to the insides.
> > 
> > But one of your goals is the use of Excalibur's SourceResolver which
> > means you automatically start using Avalon in the insides.
>
(Continue reading)

Permalink | Reply | 3 comments |
headers
Nicola Ken Barozzi | 5 Sep 2002 11:57
Picon
Favicon

Re: [FOP Avalonization] Status update + recent discussion on Avalon dev

I've set up a wiki for this discussion and others on Morhos here:
http://metamorphosis.krysalis.org/cgi-bin/mmorphosiswiki.pl?MorPhos

The page about Fop:
http://metamorphosis.krysalis.org/cgi-bin/mmorphosiswiki.pl?FopMorpher

Jeremias Maerki wrote:
> On 05.09.2002 10:20:07 Nicola Ken Barozzi wrote:
> 
>>Jeremias Maerki wrote:
>>
>>>On 04.09.2002 14:26:14 Nicola Ken Barozzi wrote:

...

>>See that discussion I had on the Avalon list about this:
>>http://nagoya.apache.org/eyebrowse/BrowseList?listName=avalon-dev <at> jakarta.apache.org&by=thread&from=233005
> 
> I've read it. At a high level I knew some of it even before that thread.
> The separation of data holder classes (FO tree, PDF objects) from
> builder (FOTreeBuilder) or writer (a future PDFSerializer) classes, for
> example. My problem is the "how to do it in reality". I'm not a good
> conceptual thinker. I usually code and then refactor until I am happy.
> That's why I sometimes have problems following the very interesting
> discussions on Avalon-Dev.

Then it means we are a balanced duo... I have your opposite problem ;-)

>>>>Let's start with touching the .apps.* package, it's the one that imposes 
>>>>bad constraint to the rest of the structure.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Nicola Ken Barozzi | 5 Sep 2002 12:15
Picon
Favicon

[Morphos] New Wiki website, UML docs, Fop Morpher discussion

Hi everyone :-)

Morphos is slowly but constantly gaining developers, interest and code.
Thanks to all :-)
                          <><><>

I've set up a Wiki to add docs and discussions to [1].
Sven, if you want to document the current status, now is the time ;-) 
<hint hint, nudge nudge>

                          <><><>

There are also UML graphs  <at>  [2].

                          <><><>

We are discussing over at the Fop list about making Fop rely on Morphos. 
You can read the proceedings here [3].

                          <><><>

Finally, following the discussion on avalon-dev on the InfoMover, we 
need to finalise the Morphos interfaces basing the discussion on 
"stateless" Morphers, that have one config and multiple atomic runs, 
essentially for scalability. [4]
And define how to pipeline correctly.

         ------------------------------------------

[1]http://metamorphosis.krysalis.org/cgi-bin/mmorphosiswiki.pl?MorPhos
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jeremias Maerki | 5 Sep 2002 14:56
Picon
Favicon

Re: [FOP Avalonization] Status update + recent discussion on Avalon dev

The wiki is nice. Should we continue to discuss on this list (or on
commons-dev if appropriate) or in the wiki or both? I don't like
redundancy.

Does the wiki have email-notification when changes are made? I've seen
no such thing. That way we could discuss in the wiki.

By the way, I've added the API requirements document to the wiki for
reference.

Jeremias Maerki
Permalink | Reply | 1 comment |
headers
Nicola Ken Barozzi | 5 Sep 2002 15:21
Picon
Favicon

Re: [FOP Avalonization] Status update + recent discussion on Avalon dev


Jeremias Maerki wrote:
> The wiki is nice. Should we continue to discuss on this list (or on
> commons-dev if appropriate) or in the wiki or both? I don't like
> redundancy.

I tend to use a Wiki for conclusions we get to and important parts of 
the discussion.
As for the discussion, since it's about FOP, I suggest a crosspost with 
commons and FOP.
And make the important things go in the Wiki too.

> Does the wiki have email-notification when changes are made? I've seen
> no such thing. That way we could discuss in the wiki.

I can set it up, but where should it notify?
The Wiki is not only for Morphos, there are other projects that use it.

> By the way, I've added the API requirements document to the wiki for
> reference.

:-)

--

-- 
Nicola Ken Barozzi                   nicolaken <at> apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------
Permalink | Reply | 0 comments |
headers
Jeremias Maerki | 5 Sep 2002 16:33
Picon
Favicon

Another API idea

My head's smoking at the moment. After reading the InfoMover threads
again and thinking about performance/tread-safety implications of
various approaches I can't think clearly anymore. That's why I simply
dump an idea on the API I've had 6 weeks ago for now. It's not related
to Morphos and but rather orients itself on JAXP. Maybe it helps for
this discussion.

//Setup XSL transformation
TransformerFactory tf = TransformerFactory.newInstance();
Source xslt = new StreamSource(myStylesheetURL);
Transformer t = tf.newTransformer(xslt);
Source src = new StreamSource(File myxmlfile);

//Setup FOP
FOProcessorFactory fopFactory = new FOProcessorFactory();
fopFactory.setOutputFormat("application/pdf");
// or:
// Properties outputProps = new Properties();
// outputProps.put("compressed", "false");
// fopFactory.setOutputFormat("application/pdf", Properties props);
fopFactory.setProperty("baseURL", "file://D:/Temp");

//Prepare Processor
FOProcessor fop = fopFactory.newProcessor();
Result pdfres = new StreamResult(File mypdffile);
// for AWT: AWTResult
fop.setResult(pdfres);

//Start transformation
t.transform(src, fop.getResultForJAXP());
(Continue reading)

Permalink | Reply | 0 comments |
headers
Peter B. West | 5 Sep 2002 17:36
Picon
Picon

Re: Notes on properties(2)

Tony,

Do you have any observations on the rest of the posting?  E.g. the 
meaning of "specified" in shorthands and short-form compounds, or the 
disappearing differences between the handling of inheritance in each 
case.  There is a proscription on inheriting shorthands, but _de facto_ 
inheritance is handled by the inheritance of the individual constituent 
properties.  When _de facto_ inheritance is applied to a compound, it is 
handled in the same way.  So the difference seems to come down to the 
fact that it is explicity allowed, both by the 'inherit' keyword and the 
inherited-property-value() function, on compounds.  Is this reasonable?

Incidentally, I am assuming that the term "inherited property" refers to 
the union of the set of properties which are specified with "Inherited: 
yes" and the set of properties on which the 'inherit' keyword is allowed.

Peter

Tony Graham wrote:
> Peter B. West wrote at  3 Sep 2002 13:05:28 +1000:
>  > I think that all of the necessary priorities amongst the properties can 
>  > be handled in this way by arranging the list as follows.
>  > 
>  > Firstly, FONT and FONT_SIZE in that order.
> 
> Firstly column-number and number-columns-spanned, otherwise you'll
> never work out 'font-size="from-table-column()"'.

--

-- 
Peter B. West  pbwest <at> powerup.com.au  http://www.powerup.com.au/~pbwest/
(Continue reading)

Permalink | Reply | 10 comments |
headers
Jeremias Maerki | 5 Sep 2002 18:03
Picon
Favicon

Checkstyle

I've just committed an optional Ant target to generate a Checkstyle
report over the FOP codebase. I didn't include the jar since this will
be something primarily for committers. You can get Checkstyle from
http://checkstyle.sourceforge.net.

Just put the checkstyle-all-3.2.jar in the lib directory and call "build
checkstyle". This generates a textfile with the report. If you copy the
file contrib/checkstyle-noframes.xsl from checkstyle into FOPs root
directory you will also get a HTML formatted report.

We've got around 9100 violations with my current settings at the moment.
I've tried to match them as closely as possible to the current codebase.
Please review the settings and tell me if we should change anything. I'm
going to start fixing violations shortly. Any help is appreciated
especially with the javadocs.

Jeremias Maerki
Permalink | Reply | 1 comment |

Gmane