Re: [VOTE RESULT] Release XML Graphics FOP 2.8

[The Web Maestro]

Thank you Simon!

Have a great day all!

Clay

On Tue, Nov 8, 2022 at 11:55 PM Simon Steiner 
wrote:

> Hi,
>
> 3+1s, I will make a release
>
> Thanks
>
>
>
>
>
>
> --

Kind regards,

Clay Leeds
--
 - 
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

Re: [VOTE] Release XML Graphics FOP 2.8

[The Web Maestro]

+1

Thanks Simon! 🌞

On Wed, Nov 2, 2022 at 6:45 AM Simon Steiner 
wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Hi,
>
> This is a vote to release XML Graphics FOP 2.8.
>
> Artifacts can be found there:
> http://people.apache.org/~ssteiner/fop-2.8/
>
> The release is signed with the key:
> https://people.apache.org/~ssteiner/KEYS
>
> The vote will end on 9/11/2022
>
> +1 from me.
>
> Thanks
> -BEGIN PGP SIGNATURE-
>
> iQIzBAEBCgAdFiEEXJow/yKywC8wJhwwW5Px33zbbeoFAmNickcACgkQW5Px33zb
> berZQw/+LlVcNnQrPi6LLh7u/AN2ummqap2wMyTc6XG2r3z4rI0QY+XumCLULTWT
> HE0pB8Oj/vLdKeTEwVYUNcDCSsaePdb3m2LQbklY3Q3D9uhBG9g4bNxJzg9VUjeZ
> /7oq0KHtY62/YuoWY0z6YdIPEiRftZrsCnCRitHXp1O/OUUpQBoxxJkmvg8hxv+Y
> 4xUfI9kvdhnEVwuAkKd0RQ4Q3Ra0NLH8twsH63UZs20eSrJBnaxtpx3N77Sjmg5p
> krJ7oXbcEgyh2aj64Hlh7phmIJXPNDt6ieLyOzti4+WoY82kTpuzpooXaJtaLhSo
> FPaXRs9HgRJtoRDwmS58Ps5ngStJ4B2LtAGqEQRxV4YQpXA4WyMwoX2DFg+V1n/K
> 7BEARc5ouTnd7Rvxdntp+yIoiYslDOPvPpdGGHhWyyeqT3vr8bjCD/TIK1NMGvY7
> WCcLzH65I9fy9sMrW/2FIXO7Gvt7qW4CYhAcmQu91GgeFyXshx2lQ04YNZlfZjfo
> h+d4+LqwkFpbnqU9a9BTs5n/ViscMK7xsHwnwNXQgTYW5ZK7eBDP7YaO8iBKEpdl
> asYGmRuA+AxAUq76dY5q3iJCJZyqOS8jVvKjY+4cc25WL/dG9M9CJ5cMLycxltBT
> I9XwaNk4lRuPNEPF6xj14a+aLynczZRgQJ9PBmXEkAfZTMpHZSg=
> =+mvZ
> -END PGP SIGNATURE-
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@xmlgraphics.apache.org
> For additional commands, e-mail: general-h...@xmlgraphics.apache.org
>
> --

Kind regards,

Clay Leeds
--
 - 
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

Re: [VOTE] Release XML Graphics FOP PDF Images 2.8

[The Web Maestro]

+1

Thanks Simon!

On Wed, Nov 2, 2022 at 6:45 AM Simon Steiner 
wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Hi,
>
> This is a vote to release XML Graphics FOP PDF Images 2.8.
>
> Artifacts can be found there:
> https://people.apache.org/~ssteiner/fop-pdf-images-2_8/
>
> The release is signed with the key:
> https://people.apache.org/~ssteiner/KEYS
>
> The vote will end on 9/11/2022
>
> +1 from me.
>
> Thanks
> -BEGIN PGP SIGNATURE-
>
> iQIzBAEBCgAdFiEEXJow/yKywC8wJhwwW5Px33zbbeoFAmNicrkACgkQW5Px33zb
> beooTw/+IdfB8hsworfVhVt9fB3VLTadU1Pa7qrVBHQmIzkiL7Hr2Oahcf69f3SE
> 5V7x7mymdtm2I3kLLi4tveMqPlMN6iOmbm6qDI2j/xjB7qSyxQSeVynOy3PnGmOk
> 5oDGIIV0o+7LE92VWF5cKuzKK03HlFXMRcK184+nXQo5dejlgVA2DtwGlxvvGMto
> NY7oSuDcg46lFH4Q6KlVOeTv6+AOd2dc+mmubgNmfGJL9MkqFuDwAnGpRrgolQwP
> F2I7FCMc/4jiRJ827yqwL2gjHtvoF6T6evpCxv3juReGDYCIuUaE2zx7YV+64GRe
> Z3+GWOBfgDC5pXVT7DVE+oJnoTpjcuL3gjH5vBSBctBT9vafSncAiirHgDnfSudQ
> 3ElXnFioR2v+Fu4+bfj9jo6nmd0suRq00lTTBL9CliP2UX3M7z5ajLKTk0O4Qs3L
> YvcCAv+hoPxm0/ucQsUGZXPIjIJYNLFzaaRh2+KdVFH62au2ok8jcdKOm07UK08K
> u01ZrnAmkbOEI+QTVeUIDfZQdlcRbvNrJUf5fDooKtg+/oqXLNQCSd0nMIhUP1CN
> Ujfxwkh3PpKI1A0uoI4FZSxeyjRfYB+AS3j57y4+yfQOu65nXMAASEbSu5UTFAFG
> NwJlwOc9iTbsvEmk4qv2E3XCO/2lvB6mSXfxyhE2aMPi9Fvv4LA=
> =ODD1
> -END PGP SIGNATURE-
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@xmlgraphics.apache.org
> For additional commands, e-mail: general-h...@xmlgraphics.apache.org
>
> --

Kind regards,

Clay Leeds
--
 - 
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

Re: Java 8

[The Web Maestro]

Sorry for the delay!

+1

On Thu, Feb 3, 2022 at 12:38 AM Simon Steiner 
wrote:

> Hi,
>
> I am going to bump a dependency on our commons and fop trunk, that requires
> java 8. This means java 7 will no longer be supported for our next release.
>
> Thanks
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@xmlgraphics.apache.org
> For additional commands, e-mail: general-h...@xmlgraphics.apache.org
>
> --

Kind regards,

Clay Leeds
--
 - 
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

Re: [Vote] for the merge of Temp_RoundedCorners

[The Web Maestro]

On Fri, Oct 12, 2012 at 7:25 AM, Pascal Sancho  wrote:
> Yes, CSS3 naming is easier to understand.
> And like other border-* properties, top, right, bottom, left should be
> mapped to equivalent FO directions in lr-tb mode (respectively before,
> end, after, start).

Yes... We've got two 'standards' to follow here: XSL-FO and CSS3.
Where possible, I'd like to err on the side of CSS3, since that is so
much more widely used. In fact, where (if?) there are discrepancies
between the CSS3 & XSL-FO methods, we may want to consider creating
'aliases' for one, that translates to the other... That could
introduce bugs, and maintenance might be another issue, but it's
something to consider.

Clay

Re: [Vote] for the merge of Temp_RoundedCorners

[The Web Maestro]

Sounds good!

+1 from me!

Kind regards,

Web Maestro Clay
--
 - 
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet


On Fri, Oct 12, 2012 at 2:40 AM, Peter Hancock  wrote:
> Hi,
>
> Luis Benardo and Myself have just done some clean up to the branch
> Temp_RoundedCorners.  This branch implements support for 'fox'
> extension properties  for specifying borders with rounded corners.
> Please refer to [1] and [2] for details.
>
> There is an example fo [3] that demonstrates the feature.
>
> Currently we are supporting:
>   PDF, PS and AFP outputs
>   'border-style' property with values of  'solid', 'none', 'hidden'
> and, to a limited degree, 'dashed'
>
> I would like to start a vote to merge feature branch to trunk, with my +1.
>
> Thanks,
>
> Peter
>
> [1] http://wiki.apache.org/xmlgraphics-fop/RoundedBorders
> [2] http://xmlgraphics.staging.apache.org/fop/trunk/extensions.html
> [2] examples/fo/advanced/rounded-corners.fo in the Temp_RoundedCorners branch

Re: [VOTE] Merge Temp_URI_Unification

[The Web Maestro]

I'm a bit confused... Am I correct that this [VOTE] relates to merging
the Temp_URI_Unification to fop/trunk and not to FOP-1.1rc*? If so,
then +1 and if not then +0 since I don't quite understand... (not
blocker, but not enough info for me to +1... ;-)

Kind regards,

Clay Leeds
--
 - 
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet


On Wed, Jul 4, 2012 at 9:26 AM, Chris Bowditch
 wrote:
> On 04/07/2012 17:15, Glenn Adams wrote:
>>
>>
>> On Wed, Jul 4, 2012 at 9:25 AM, mehdi houshmand > > wrote:
>>
>> On 4 July 2012 12:32, Vincent Hennebert > > wrote:
>>
>>
>> There does seem to be a regression. Before, the
>> FopFactoryConfigurator
>> object was getting the strict-validation element from the
>> config file
>> and calling FopFactory.setStrictValidation if it was set to
>> true. This
>> is no longer the case.
>>
>> I’ve just tried to render a table with table-footer after
>> table-body,
>> and now a validation error is thrown even if I have
>> strict-validation
>> set to false in my config file. No validation error was thrown
>> before.
>>
>>
>> I've fixed the underlying issue but this is an interesting one; it
>> isn't obvious that settings from the fop conf override the
>> settings from the command line options. (Pete probably wrote this
>> part hahaha ;) )
>>
>>
>> They shouldn't. Command line options should override the conf file.
>>
>
> Agreed, but IIUC, the team just copied the existing functionality due to
> time constraints. We should probably log a bug to track that as an issue.
>
> Thanks,
>
> Chris
>
>

Re: new xgc release required for fop 1.1 release?

[The Web Maestro]

On Wed, May 30, 2012 at 8:18 AM, Pascal Sancho  wrote:
> Hi Glenn,
>
> 1.1rc1 sounds good for me.
> If further RC is required, the only final digit needs to be incremented.
> In addition, this version name indicates by itself that this version should
> not be used in prod.

So I think that would be:

- fop-1.1rc (svn-tag: fop-1_1rc)
- commons-1.5rc (svn-tag: commons-1_5rc)

Should this be on general@?

Kind regards,

Clay Leeds
--
 - 
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

Re: on changing fop documentation sources to markdown

[The Web Maestro]

On Sat, Apr 21, 2012 at 9:42 AM, Clay Leeds wrote:

> On Apr 20, 2012, at 1:36 AM, Pascal Sancho 
> wrote:
>


> But there has to be a better way. Can we, as a start, change the CSS file
> xmlgraphics.css so it doesn't have body {color: white;}?
>
> > Note that I have to be very patient when editing the (very long)
> compliance page directly, since it is rendered directly in the preview
> pane. Don't try it if your processor is a little out of age (;-|
>
> > [1] http://www.apache.org/dev/cmsref.html#markdown
>
> Thanks again for the assistance!
>
> Clay


I've committed a change to the CSS, which at least makes it black text on
white background (white on white is difficult to read unless you're a
wizard!).

We'll still need to figure out a solution for the coloring and such... We
should be able to come up with some solution... If nothing else, we could
always commit an HTML file, but we need to find a method to make it so the
CMS doesn't replace it or something silly...

Hand editing all the lines in that file just doesn't seem efficient!

Re: on changing fop documentation sources to markdown

[The Web Maestro]

On Thu, Apr 19, 2012 at 12:40 AM, Chris Bowditch  wrote:

> On 19/04/2012 02:02, Clay Leeds wrote:
>
>> I replaced the logo for all sites a month or so ago.
>>
>
> Thanks Clay - I can see the new logo fine. I was referring to the "TM"
> characters in the text. I can see it everywhere except the top level XML
> Graphics home page, which is a page I definitely changed.


Sorry, thought you were talking about the graphic. I fixed the text.

BTW, it's pretty easy for anyone to edit with the CMS now. Here's the
Apache CMS Reference:

http://www.apache.org/dev/cmsref.html

That will give you a bookmarklet you can use to edit any STAGING page:

Here's your starting point for the XML Graphics Staging site:

http://xmlgraphics.staging.apache.org/

Once we're good to go, anyone will also be able to start editing the
markdown files themselves...

Cheers!

Clay

Re: on changing fop documentation sources to markdown

[The Web Maestro]

On Tue, Apr 17, 2012 at 7:52 AM, Chris Bowditch
wrote:

> BACKGROUND:
>> We are discussing moving XML Graphics web site to ASF-CMS. You can see
>> progress here:
>>
>> http://xmlgraphics.staging.**apache.org/
>>
>
> I realize its work in progress but it appears like you used an old
> snapshot without the "TM" marks in the content or the new logo that you
> designed. Also the links need to include License, Sponsorship, Thanks and
> Security as per the branding guidelines. This content is now live on the
> main site, so I guess you just started with a snapshot from a few weeks ago?


I added the logo (in GIF, JPG, PNG & SVG formats... ;-)

Sponsorship & Thanks were already there. License is on the Legal page,
which is there, but I've added it to the sidebar as well, along with the
Security page. ;-)

I also got the Compliance table working. Unfortunately, the CMS is
stripping the 'class="ForrestTable"', so the coloring is White-On-White
(but if you select the text, you'll see the content and layout is there).

As for the navigation menu, I'd like it to collapse most of the links,
except the section you're in. Anyone have a favorite jQuery menu they like
for this? If not, I'll see about finding one...

Clay

Re: on changing fop documentation sources to markdown

[The Web Maestro]

I just added most of the nav for FOP Development (0.95, 1.0, trunk/ and
'dev'):

http://xmlgraphics.staging.apache.org/

As mentioned, there are likely missing things (like java-docs,
download.cgi, Batik's DEMO, etc.)... It'd be great if folks could take a
look... I haven't figured out how to add other content, but It Might Just
Work(tm) if weupload it there via SVN...

Come to think of it, we should probably move this to
gene...@xmlgraphics.apache.org. Or is there a better mailing list? I'll
refrain from sending to other lists, until we figure out where it should go.

Any ideas where this discussion should move, since it entails changes to
all XML Graphics Project web docs?

Kind regards,

Clay Leeds
--
 - <http://ourlil.com/>
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet


On Sat, Apr 14, 2012 at 11:53 PM, The Web Maestro
wrote:

> I've updated the docs a bit, and gotten much (but not all!) of the FOP,
> Batik & Commons content into the CMS...
>
> We're still missing an adequate navigation system, so I did a preliminary
> job of getting a few links in the sidenav, but it's incomplete and ugly as
> sin. We'll need to build a mechanism to hide (collapse?) non-relevant
> links, but that shouldn't be too hard.
>
> We also need to figure out java-docs, download.cgi, and perhaps some other
> issues...
>
> Without further ado:
>
> http://xmlgraphics.staging.apache.org/
>
>
> Kind regards,
>
> Clay Leeds
> --
>  - <http://ourlil.com/>
> My religion is simple. My religion is kindness.
> - HH The 14th Dalai Lama of Tibet
>
>
> On Thu, Apr 12, 2012 at 10:03 PM, Clay Leeds wrote:
>
>> On Apr 12, 2012, at 6:41 AM, Glenn Adams  wrote:
>> > Agreed that removing forrest dependency is desirable. However,
>> presumably the current xdocs would need to be converted to MD, in which
>> case someone will need to construct an XSLT to do so. That begs the
>> question of whether it would be necessary (at this time) to convert the
>> source format to MD, or if an additional step in the CMS based process
>> could merely perform that step automatically. If so, then it should not be
>> necessary to change the authoring format at this time. It could be done as
>> a separate step later.
>>
>> I am using Forrest 0.8 w markdown plugin. Conversion could be scripted,
>> but that would negate the benefit of the CMS.
>>
>> > What I don't know yet is what we will lose from the conversion to MD in
>> terms of ability to markup our source docs. Clearly, MD is not as
>> semantically or syntactically rich as an XML based source. But do we lose
>> anything of consequence? I don't know yet.
>> >
>> > One thing we may lose if we don't convert to MD is the ability to use
>> CMS in-page editing. So that is a consideration. Perhaps that option is
>> sufficient to justify other potential negatives in converting.
>> >
>> > G.
>>
>> One of my goals, was to see some discussion in the DEVers, before I
>> complete the task of converting the docs. The MarkDown format is not nearly
>> as semantic as xdoc, but it serves a different purpose.
>>
>> It'll take some time, and I'm still prepared to take it on. But I was
>> hoping for some discussion ;-)
>>
>>
>

Re: on changing fop documentation sources to markdown

[The Web Maestro]

I've updated the docs a bit, and gotten much (but not all!) of the FOP,
Batik & Commons content into the CMS...

We're still missing an adequate navigation system, so I did a preliminary
job of getting a few links in the sidenav, but it's incomplete and ugly as
sin. We'll need to build a mechanism to hide (collapse?) non-relevant
links, but that shouldn't be too hard.

We also need to figure out java-docs, download.cgi, and perhaps some other
issues...

Without further ado:

http://xmlgraphics.staging.apache.org/

Kind regards,

Clay Leeds
--
 - 
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet


On Thu, Apr 12, 2012 at 10:03 PM, Clay Leeds wrote:

> On Apr 12, 2012, at 6:41 AM, Glenn Adams  wrote:
> > Agreed that removing forrest dependency is desirable. However,
> presumably the current xdocs would need to be converted to MD, in which
> case someone will need to construct an XSLT to do so. That begs the
> question of whether it would be necessary (at this time) to convert the
> source format to MD, or if an additional step in the CMS based process
> could merely perform that step automatically. If so, then it should not be
> necessary to change the authoring format at this time. It could be done as
> a separate step later.
>
> I am using Forrest 0.8 w markdown plugin. Conversion could be scripted,
> but that would negate the benefit of the CMS.
>
> > What I don't know yet is what we will lose from the conversion to MD in
> terms of ability to markup our source docs. Clearly, MD is not as
> semantically or syntactically rich as an XML based source. But do we lose
> anything of consequence? I don't know yet.
> >
> > One thing we may lose if we don't convert to MD is the ability to use
> CMS in-page editing. So that is a consideration. Perhaps that option is
> sufficient to justify other potential negatives in converting.
> >
> > G.
>
> One of my goals, was to see some discussion in the DEVers, before I
> complete the task of converting the docs. The MarkDown format is not nearly
> as semantic as xdoc, but it serves a different purpose.
>
> It'll take some time, and I'm still prepared to take it on. But I was
> hoping for some discussion ;-)
>
>

Re: on changing fop documentation sources to markdown

[The Web Maestro]

On Fri, Mar 30, 2012 at 8:55 AM, Glenn Adams  wrote:

> On Fri, Mar 30, 2012 at 7:00 AM, Clay Leeds wrote:
>
>> Makes sense to me. However, I don't think it's necessary to have all
>> documentation as such.  Perhaps just the Day to day stuff can be translated
>> (things that are more likely to change).
>>
>
> There aren't too many docs whose content change on a frequent basis.
> Probably only the status.xml content.
>
>
>> That's my current plan, anyway (although I don't yet know how to make
>> that happen). Ye olde documentation can remain on xdoc format, or better
>> yet get converted to Docbook format.
>>
>
> I certainly have no problem with using MD as the source format for README
> and similar content, and would suggest these be converted to MD. I do have
> a problem with replacing current XML marked up xdoc sources with MD
> sources, though I'd be open to considering this on a case by case basis if
> there is good cause.
>

I understand the desire to retain the XML-based format of the
documentation. My primary purpose in doing the migration, was to see if it
would be as easy as pie to get the data converted to CMS-based format. I've
got more work to do (namely, to get the versioned docs => MarkDown), but it
was pretty simple. Updating is *way* more simple than the Forrest-based
method.


> Regarding XML source formats, right now we have xdoc, and it would take
> some effort for probably questionable results to convert to another XML
> schema. Plus that would require some additional learning curve or tool
> change for authors, so I'm not sure about changing to another XML format.
>

Thanks to a Forrest 'MarkDown' plugin, it doesn't take too long to convert
from xdoc to MarkDown.


> For output formats, obviously we need HTML, but if it is useful to output
> MD, then I see no problem with someone adding that to the publish build
> process. I think it is useful to also continue publishing in PDF output
> format as well, if for no other reason than to exercise FOP. Otherwise, I
> don't have any strong preferences. For example, I have no love for forrest
> if another doc management system will be an improvement.
>

On the side of losing the FOP part of the docs process, perhaps one
possibility for FOP's site eating its own dogfood, would be if we could
create a web service to generate PDF from each web page, perhaps
using PDFBox[1] or HTML2fo[2], which is a bit stale but useful.

So if you can find a way to transition to CMS as the doc management system
> while still reusing the existing source formats and output formats (modulo
> the above), then I have no objection to that.
>

Yes, we'd lose the XML-based nature of the documentation. That's a fairly
large loss, but I don't know if that's a showstopper, considering the
benefits of having CMS-based documentation.

[1] Apache PDFBox
http://pdfbox.apache.org/

[2] HTML2fo
http://html2fo.sourceforge.net/

Kind regards,

Clay Leeds
--
 - 
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

Re: Working on getting the web site converted to Apache's ASF-CMS...

[The Web Maestro]

On Tue, Mar 20, 2012 at 3:59 AM, Vincent Hennebert wrote:

> A change that I personally welcome. Quite frankly the PDF versions of
> our web pages look terrible and don’t do honour to FOP. And I’ve never
> been comfortable enough with Forrest to change the way they look. And
> I must say, I don’t have the energy to learn enough of Forrest to be
> able to do it.
>
> I’m happy with the all-CMS and Markdown approach, especially if it can
> give our website a 21st century look.
>
> Vincent
>

Apologies for the making you create a new /dev/null^H^H^H^H^H mail rule to
re-direct buildbot msgs...

Well, we don't quite have the 21st century look I was hoping for yet, but
I've got a few pages on the new staging site:

http://xmlgraphics.staging.apache.org/

We're still very prelminary. I haven't done much with the look & feel yet,
but we're on our way... It took me a bit to get Forrest outputting
'MarkDown' format (insert story about Mac OS X, downgrading Java, and
multiple versions of Forrest).

I need to figure out how to make a sidebar/navigation bar (I'm hoping for a
common one!). I also need to get sub project pages up.

Of course, I/we have yet to determine exactly how we'll go about handling
the Documentation.

If you'd like to start messing around, you can start here:

https://cms.apache.org/#bookmark

and this'll help:

http://www.apache.org/dev/cmsref.html

Cheers!

Web Maestro Clay

Re: Merging Temp_PDF_ObjectStreams branch to trunk

[The Web Maestro]

+1 Thanks!

Kind regards,

Clay Leeds
--
 - 
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet



On Thu, Mar 22, 2012 at 4:52 AM, Craig Ringer  wrote:
> On 03/22/2012 03:54 PM, Pascal Sancho wrote:
>>
>> Hi,
>> +0
>> I see no objection if PDF-image plugin is updated in a short delay
>> (I mean: before next release).
>
> This might be a good opportunity to merge fop-pdf-image .
>
> --
> Craig Ringer

Re: Working on getting the web site converted to Apache's ASF-CMS...

[The Web Maestro]

On Mon, Mar 19, 2012 at 11:45 AM, Vincent Hennebert
 wrote:
>> My intention is to build the web site in CMS, and then having
>> discussions, etc. *before* converting the site! There should
>> definitely be advance notice prior to the change.
>
> So both sites would co-exist for a while, only the Forrest-generated one
> being visible from xmlgraphics.apache.org ATM? Is it possible to have
> (and play with) a preview of the CMS version?

That's the plan...

>> If in my stumbling, an issue occurs with premature deployment I will
>> work quickly to resolve! That would certainly not be my intention, but
>> accidents happen! I am doing my best to ensure that does *not* happen!
>>
>> My current plan is to put some day-to-day pages in the CMS, and then
>> export all Forrest-based documentation to Markdown formatted
>> documents, for import to the CMS system according to this plugin:
>>
>> http://forrest.apache.org/pluginDocs/plugins_0_80/org.apache.forrest.plugin.output.Markdown/
>
> Does that mean that we would be eventually phasing out Forrest
> altogether and store the documentation directly in the CMS?

Yes. We hope to phase out Forrest... All content changes will occur in the CMS.

Part of the process will *hopefully* involve migrating our current
docs from Forrest to Markdown styled pages using the above Forrest
Markdown plugin.

> Also, is there any chance that we will be able to factorize content that
> is common to all XML Graphics websites? Among other things, I’m thinking
> of the ApacheCon events. ATM we have to update them on each of the 4 XML
> Graphics websites, which is a real pain.

It will all be one site, so that will no longer be an issue.

>> At present I don't have an ETA, but I hope to make good progress over
>> the coming weeks.
>
> There’s no rush ATM, but if for any reason you think you won’t be able
> to complete this by, say, the start of the summer, could you let us
> know? We will try to take over from where you’ve got.

Will do!

> Good luck,
> Vincent

Thanks!

Working on getting the web site converted to Apache's ASF-CMS...

[The Web Maestro]

Hi folks,

You may've noticed some shenanigans as I was preparing the XML
Graphics site to the new ASF CMS system. In particular, I've added
xmlgraphics/site/trunk/ and xmlgraphics/site/branches/ in preparation
of the CMS deployment.

My intention is to build the web site in CMS, and then having
discussions, etc. *before* converting the site! There should
definitely be advance notice prior to the change.

If in my stumbling, an issue occurs with premature deployment I will
work quickly to resolve! That would certainly not be my intention, but
accidents happen! I am doing my best to ensure that does *not* happen!

My current plan is to put some day-to-day pages in the CMS, and then
export all Forrest-based documentation to Markdown formatted
documents, for import to the CMS system according to this plugin:

http://forrest.apache.org/pluginDocs/plugins_0_80/org.apache.forrest.plugin.output.Markdown/

At present I don't have an ETA, but I hope to make good progress over
the coming weeks.

Kind regards,

Clay Leeds
--
 - 
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

Re: [VOTE] Mehdi Houshmand for FOP committer

[The Web Maestro]

I vote +1 for Mehdi to be a committer! He's already been a great
positive asset to the community.

I look forward to working even more closely with you Mehdi!

Regards,

The Web Maestro
--
 - <http://ourlil.com/>
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet



On Thu, Nov 10, 2011 at 6:18 AM, Chris Bowditch
 wrote:
> Dear FOP committers,
>
> Mehdi has submitted dozens of high quality patches and regularly
> participates on the mailing lists. Mehdi is already an official FOP
> Contributor. I propose Mehdi Houshmand as a FOP committer.
>
> I vote +1
>
> Replies to general@ please.
>
> Thanks,
>
> Chris
>

Re: [VOTE] Merge branch Temp_ComplexScripts into trunk

[The Web Maestro]

> Following this request, I herewith propose to merge the branch
> Temp_ComplexScripts into trunk, and launch a formal vote.
>
> I vote positive: +1
>
> For the rules of voting about code commits, see the project charter,
> article 11, http://wiki.apache.org/xmlgraphics/ProjectCharter.
>
> Simon Pepping

This sounds good to me, but I want to ask:

Does this new feature have any impact on people not using Complex
Scripts in their FOP process?

Regards,

The Web Maestro
--
 - <http://ourlil.com/>
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

Re: svn commit: r1141997 - /xmlgraphics/fop/tags/fop-1_0/src/documentation/skinconf.xml

[The Web Maestro]

Doh! My mistake. I guess I'm a bit rusty at this. Need to make more changes, 
more often. 

Thanks, Vincent for cleaning up my mess!

Clay

"My religion is simple. My religion is kindness."
- HH the Dalai Lama of Tibet

On Jul 1, 2011, at 10:25 AM, vhenneb...@apache.org wrote:

> Author: vhennebert
> Date: Fri Jul  1 17:25:44 2011
> New Revision: 1141997
> 
> URL: http://svn.apache.org/viewvc?rev=1141997&view=rev
> Log:
> Reverted changes made in rev. 1139721, 1139722, 1140594. This branch is a tag 
> and must not change.
> 
> Modified:
>xmlgraphics/fop/tags/fop-1_0/src/documentation/skinconf.xml
> 
> Modified: xmlgraphics/fop/tags/fop-1_0/src/documentation/skinconf.xml
> URL: 
> http://svn.apache.org/viewvc/xmlgraphics/fop/tags/fop-1_0/src/documentation/skinconf.xml?rev=1141997&r1=1141996&r2=1141997&view=diff
> ==
> --- xmlgraphics/fop/tags/fop-1_0/src/documentation/skinconf.xml (original)
> +++ xmlgraphics/fop/tags/fop-1_0/src/documentation/skinconf.xml Fri Jul  1 
> 17:25:44 2011
> @@ -15,20 +15,20 @@
>   See the License for the specific language governing permissions and
>   limitations under the License.
> -->
> +
> 
> - "http://forrest.apache.org/dtd/skinconfig-v08-2.dtd";>
> +
> + "http://forrest.apache.org/dtd/skinconfig-v06-3.dtd";>
> 
> -
>provider="google"/>
> 
> @@ -60,7 +60,8 @@ See main/fresh-site/src/documentation/sk
>   
>   true
>   .at.
> -
> +
> +  
>   false
> 
>   
>   
>   
> -
> -  favicon.ico
> -
> -  
> -  1999
> -  The Apache Software Foundation. Licensed under Apache License 
> 2.0
> +
> +  
> +  
> +
> +  
> +  1999-2009
> +  The Apache Software Foundation.
>   http://www.apache.org/licenses/
> -
> -  
> -Apache, Apache Forrest, the Apache feather logo, and the Apache Forrest
> -logos are trademarks of The Apache Software Foundation. All other marks 
> mentioned may be trademarks or registered trademarks of their respective 
> owners.
> -  
> -
>   
> -
> +
> +  
>   
> 
>   
> 
> @@ -303,9 +302,10 @@ See main/fresh-site/src/documentation/sk
> 
> -->
>   
> -
> + 
> +  
>   
> -Supported page sizes are a0, a1, a2, a3, a4, a5, executive,
>folio, legal, ledger, letter, quarto, tabloid (default letter).
>Supported page orientations are portrait, landscape (default
> @@ -313,7 +313,7 @@ See main/fresh-site/src/documentation/sk
>Supported text alignments are left, right, justify (default left).
> -->
> 
> -Page 1/1
> +1
>  +
> +
> false
> @@ -341,7 +342,8 @@ See main/fresh-site/src/documentation/sk
> -->
> false
>   
> - Credits are typically rendered as a set of small clickable
> images in the page footer.
> 
> @@ -376,13 +378,15 @@ See main/fresh-site/src/documentation/sk
>   125
> 
> -->
> +
> 
> 
>   PDF created by Apache FOP
> 
> 
> 
> -
> To unsubscribe, e-mail: fop-commits-unsubscr...@xmlgraphics.apache.org
> For additional commands, e-mail: fop-commits-h...@xmlgraphics.apache.org
> 

Re: Subversion merge or GIT merge? [was: Re: [VOTE] Merge FOP color branch into trunk]

[The Web Maestro]

Are you saying you think we should consider: 
a) moving from SVN to GIT
b) using GIT as a timesaver for conflicts?

Clay 

Sent from my iPhone

On Jan 29, 2011, at 12:24 PM, Simon Pepping  wrote:

> I read in the literature that GIT and Mercurial merge would be very
> much better at resolving possible conflicts than subversion. Today I
> tested this with the merge of the Temp_Color branch into trunk.
> 
> In GIT I used the GIT repository at https://github.com/apache/fop. The
> merge of Temp_Color resulted in one conflict, in status.xml. The
> conflict was presented precisely, and was easily resolved.
> 
> The merge in Subversion resulted in the following:
> 
> Summary of conflicts:
>  Text conflicts: 16
>  Property conflicts: 1
>  Tree conflicts: 68
> 
> The many tree conflicts were files that were removed in the branch and
> trunk or added in both. Obviously they were caused by the merges of
> trunk into Temp_Color earlier.
> 
> After the merge in GIT I got no compilation errors. I got three
> failures in the junit tests, which were also present in the branch. I
> investigated a few cases which gave a conflict in subversion. They
> were resolved correctly in GIT.
> 
> This merge result is a huge time saver, and I thought I should let you
> know.
> 
> Simon
> 
> On Wed, Jan 19, 2011 at 11:56:34AM +0100, Jeremias Maerki wrote:
>> I've cleaned up the color branch, tweaked a few things and did some more
>> testing. I'm happy with the current state, so I'm calling for a vote to
>> merge the current FOP color branch into trunk.
>> 
>> https://svn.apache.org/repos/asf/xmlgraphics/fop/branches/Temp_Color
>> 
>> +1 from me, obviously.
>> 
>> Jeremias Maerki
>> 

Re: [VOTE] Merge FOP color branch into trunk

[The Web Maestro]

No formal review but the code looks good. 

+1

Sent from my iPhone

On Jan 19, 2011, at 2:56 AM, Jeremias Maerki  wrote:

> I've cleaned up the color branch, tweaked a few things and did some more
> testing. I'm happy with the current state, so I'm calling for a vote to
> merge the current FOP color branch into trunk.
> 
> https://svn.apache.org/repos/asf/xmlgraphics/fop/branches/Temp_Color
> 
> +1 from me, obviously.
> 
> Jeremias Maerki
> 

Re: [VOTE] Release files for fop 1.0

[The Web Maestro]

Looks good!

+1 from me! Thank you!

"My religion is simple. My religion is kindness."
- His Holiness the Dalai Lama of Tibet

On Jul 12, 2010, at 1:29 PM, Simon Pepping  wrote:

> The release files for fop 1.0 are now ready for review and the release
> vote.
> 
> The release files were built from:
> https://svn.apache.org/repos/asf/xmlgraphics/fop/tags/fop-1_0
> (created in revision 963413).
> 
> The release files are found here: http://people.apache.org/~spepping/fop-1_0:
> 
> 3186f93a314bdcb710bd7cb02d80404c  fop-1.0-bin.tar.gz
> 262da85d77fbca68556bc74e44ecca27  fop-1.0-bin.zip
> b47043cea49a9291bc0ed369a4150dd3  fop-1.0-bundle.jar
> 95dcc4c2dd08b4bc88ce9ce1ee88c439  fop-1.0-src.tar.gz
> 8693ed0f4586d394e547a23625a64d34  fop-1.0-src.zip
> 
> As partially mentioned earlier, I used the following workaround:
> 
> jdk6:  ant distclean, docs
> jdk14 without junit: ant dist (which runs the docs target again), 
> maven-artifacts
> jdk6: junit
> 
> This uses the trick that forrest is run each time, but does not clean
> out its target directory.
> 
> With jdk14 all junit tests fail. I removed junit from the classpath
> for jdk14, and ran junit after the build with jdk6.
> 
> forrest also gives problems with jdk6:
> 
> 0.95/images/update.jpg: No pipeline matched request: 0.95/images/update.jpg
>at  - 
> file:/fsc/source/apache-forrest-0.8/main/webapp/./sitemap.xmap:600:76
> 0.95/images/fix.jpg: No pipeline matched request: 0.95/images/fix.jpg
>at  - 
> file:/fsc/source/apache-forrest-0.8/main/webapp/./sitemap.xmap:600:76
> 0.95/images/add.jpg: No pipeline matched request: 0.95/images/add.jpg
>at  - 
> file:/fsc/source/apache-forrest-0.8/main/webapp/./sitemap.xmap:600:76
> 1.0/images/update.jpg: No pipeline matched request: 1.0/images/update.jpg
>at  - 
> file:/fsc/source/apache-forrest-0.8/main/webapp/./sitemap.xmap:600:76
> 1.0/images/fix.jpg: No pipeline matched request: 1.0/images/fix.jpg
>at  - 
> file:/fsc/source/apache-forrest-0.8/main/webapp/./sitemap.xmap:600:76
> 1.0/images/add.jpg: No pipeline matched request: 1.0/images/add.jpg
>at  - 
> file:/fsc/source/apache-forrest-0.8/main/webapp/./sitemap.xmap:600:76
> 
> These images are in /images, and the problem does not seem to matter.
> 
> compliance.pdf: internal-destination or external-destination must be
> specified in basic-link. As a consequence no compliance.pdf was built.
> 
> For your perusal I uploaded the build log: 
> build-2010-07-12T22:19:58+02:00.log.
> 
> Please, review and cast your votes before Thu 15 July 19:00h UTC.
> 
> +1 from me.
> 
> -- 
> Simon Pepping
> home page: http://www.leverkruid.eu

Re: [VOTE] Release of FOP 1.0

[The Web Maestro]

So is this VOTE cancelled?

On Jul 10, 2010, at 6:37 AM, Simon Pepping  wrote:

> I am not in favor of including all jar files in lib/build in the
> source distribution. Do we use retroweaver? I seem to recall that that
> was a plan on which we did not execute. Do we need to include tools
> for PMD and Findbugs reports? Or for doing XMLUnit tests? They are not
> essential build tools, they are tools for advanced building with
> diagnostics.
> 
> I found that it i can compile when I include qdox only.
> 
> Simon
> 
> On Fri, Jul 09, 2010 at 05:36:48PM +0200, Mathieu Malaterre wrote:
>> Hi Simon,
>> 
>>  I downloaded the tarball
>> from:http://people.apache.org/~spepping/fop-1_0/fop-1.0-src.tar.gz
>> 
>> $ md5sum fop-1.0-src.tar.gz
>> bb921758e2eb4327b7ac01c5f5fec455  fop-1.0-src.tar.gz
>> 
>> It seems the ant rule should be adapted since lib/build has been
>> removed from the tarball.
>> 
>> log:
>> 
>> Buildfile: /home/mathieu/debian/pkg-java/trunk/fop/fop-1.0/build.xml
>> 
>> BUILD FAILED
>> /home/mathieu/debian/pkg-java/trunk/fop/fop-1.0/build.xml:1117:
>> /home/mathieu/debian/pkg-java/trunk/fop/fop-1.0/lib/build does not
>> exist.
>> 
>> Total time: 0 seconds
> 
> -- 
> Simon Pepping
> home page: http://www.leverkruid.eu

Re: Release version 1.0

[The Web Maestro]

You're just doing this so you have something to talk about in the next
Board update! J/k!

I bet it felt *good* to create that BugZilla entry!

Thanks for your efforts!

Clay

On Wednesday, May 12, 2010, Simon Pepping  wrote:
> Indeed, this means that I have a vague plan to work on this. Since I
> have lots of other things to do and because it is summer, I cannot
> make a firm commitment. Moreover, I filed this bug in advance, so that
> there is time for everyone to think about release critical bugs.
>
> Simon
>
> On Wed, May 12, 2010 at 03:08:44PM -0400, bugzi...@apache.org wrote:
>> https://issues.apache.org/bugzilla/show_bug.cgi?id=49281
>>
>>            Summary: Release version 1.0
>>            Product: Fop
>>            Version: 1.0dev
>>           Platform: All
>>         OS/Version: All
>>             Status: NEW
>>           Severity: normal
>>           Priority: P2
>>          Component: general
>>         AssignedTo: fop-dev@xmlgraphics.apache.org
>>         ReportedBy: spepp...@apache.org
>>
>>
>> Release version 1.0
>>
>> Step 1: List all bugs that must be solved before a release can take place
>> (release critical bugs). Make this bug depend on each release critical bug 
>> and
>> write a short argument why the bug is release critical.
>>
>> Steps 2ff: See web site.
>
> --
> Simon Pepping
> home page: http://www.leverkruid.eu
>

-- 
Regards,

The Web Maestro
-- 
 - <http://ourlil.com/>
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

Re: Reaching private@

[The Web Maestro]

Yeah I didn't see it... Thx for the re-send... FWIW, I'm sending a
private note as we discussed shortly...

Clay

On 12/1/09, Simon Pepping  wrote:
> Is it true that my two replies to private@ have not reached the list?
> Simon
>
> --
> Simon Pepping
> home page: http://www.leverkruid.eu
>


-- 
Regards,

The Web Maestro
-- 
 - <http://ourlil.com/>
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

Re: [VOTE] Merge the Temp_Accessibility Branch Back to Trunk

[The Web Maestro]

Sounds like a lofty and honorable goal.

+1 from me.

Clay
-- 
 - 
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

Re: Moving to Java 1.5, retroweaving for 1.4

[The Web Maestro]

I agree about consistency w requirements... Perhaps one additional
release req 1.4, then move to 1.5 for the next release. I don't have
any real energy about whether the 1.0 should be 1.4 or 1.5, however...
I do agree that there should be a significant version change
signalling the move from 1.4 to 1.5. Perhaps 0.96 (1.4) and 1.0 (1.5)?

If FOP is going to switch anyway, is there a compelling reason not to
req Java 1.6 instead of 1.5 for FOP 1.0 (or whatever version makes the
jump)? Would that lock out a huge number of our audience? Would
requiring 1.6 mean any significant performance or other benefit?

Clay

On 8/22/09, Max Berger  wrote:
> Dear Fop-Devs,
>
> since I am one of the people cited for moving forward to 1.5, I just
> want to throw my 2 cts in the mix:
>
> I would prefer a new release first, and then moving to 1.5.
>
> Rationale:
>
> 1) Retroweaving works, but there will be some bugs which will have to
> be ironed out and tested. The last release (0.95) has been done quite
> a long time back, and the next release will take even longer when a
> new "feature" (1.5) is added.
>
> 2) Since the 0.9x releases are "test-releases" towards 1.0, they
> should have the same features / requirements.
>
> 3) The next release (1.0.9x ? 1.9x?) could then depend on 1.5, whereas
> the 1.0 branch could stay on 1.4
>
> As an example from another apache project: Maven moved from 2.1.0 to
> 2.2.0 rather than 2.1.x because they now require java 1.5 and did not
> want to make this a "minor" upgrade"
>
> Max
>
> 2009/8/20 Simon Pepping :
>> On Thu, Aug 20, 2009 at 02:14:39PM +0100, Chris Bowditch wrote:
>>> Jeremias Maerki wrote:
>>> >There we go again. ;-) I can understand the wishes and cravings of the
>>> >developers (feeling them myself), but as I've said before: such a
>>> >decision should be made with the user community in the back, i.e. there
>>> >should be another user survey to gather current data. Just because Sun
>>> >EOLs a Java version doesn't mean that everyone can suddenly just do the
>>> >switch. So why don't those who want this change so badly do that little
>>> >survey so we have the data on an informed decision?
>>>
>>> Hi All,
>>>
>>> I'm not so against this idea 1 year further on but I still have
>>> concerns that we would force x% of users to stay on 0.95 if we do
>>> this. I agree with Jeremias' proposal to run a survey on fop-users
>>> for a couple of weeks to get some hard facts to help make an
>>> informed decision.
>>>
>>> Also, I think it is something that could wait until after the long
>>> promised 1.0 release. With the changing IPD feature being one of the
>>> last major features of 0.20.x missing from 0.9x that is now
>>> available we should consider doing the v1.0 release and then if the
>>> survey shows the number of 1.4 and earlier users to be very low then
>>> we should do the switch.
>>
>> I agree that we should proceed with a 1.0 release.
>>
>> I can also agree with releasing it compliant with Java 1.4.
>>
>> I note, however, that the methods I removed were several methods in
>> class Character which are very useful in character handling, such as
>> the method Character.toChars(int), which is the main method to convert
>> an integer to an array of chars. That means that for Unicode values
>> above 0x there is no good method to turn the value into a char[]
>> or String. Also Characters.toLowerCase, toUpperCase, toTitleCase,
>> getType, $UnicodeBlock. For a text handling application in 2009 that
>> is a bit painful.
>>
>> Simon
>>
>> --
>> Simon Pepping
>> home page: http://www.leverkruid.eu
>>
>


-- 
Regards,

The Web Maestro
-- 
 - <http://ourlil.com/>
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

Re: [VOTE] Merge the ChangingIPDHack Branch Back to Trunk

[The Web Maestro]

Another 'No time to test it!' +1 from me...

Clay

On 8/20/09, Vincent Hennebert  wrote:
> Hi All,
>
> Having had no feedback from the users list, I’m happy to announce that
> the ChangingIPDHack branch is now totally bug-free :-)
>
> Following the discussion on general@ [1], the best way to handle this
> probably is to merge the changes back into the Trunk, even if they are
> hacky. Maintaining a separate branch may turn out to be more
> time-consuming than reverting the merge once work on a new layout engine
> starts.
>
> So I’d like to launch a vote for merging the following branch:
> https://svn.eu.apache.org/repos/asf/xmlgraphics/fop/branches/Temp_ChangingIPDHack
> into Trunk.
>
> +1 from me.
>
> [1] http://markmail.org/message/ypn2p6c27gjx3vzi
>
>
> Thanks,
> Vincent
>


-- 
Regards,

The Web Maestro
-- 
 - <http://ourlil.com/>
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

Re: How to locate missing glyph in fo file

[The Web Maestro]

Fop-dev@xmlgraphics.apache.org is for FOP development. Please repost
your question to fop-us...@xmlgraphics.apache.org our FOP user list.
Thanks!

On 3/6/09, Dongsheng Song  wrote:
> ...
> [WARN] FOUserAgent - Line 1 of a paragraph overflows the available
> area by more than 50 points. (See position 11935:439)
> [WARN] FOUserAgent - Line 1 of a paragraph overflows the available
> area by more than 50 points. (See position 12922:1177)
> [WARN] FOUserAgent - Line 1 of a paragraph overflows the available
> area by more than 50 points. (See position 12922:1177)
> [WARN] FOUserAgent - Line 1 of a paragraph overflows the available
> area by more than 50 points. (See position 12922:1177)
> [WARN] FOUserAgent - Line 1 of a paragraph overflows the available
> area by more than 50 points. (See position 12922:1177)
> [WARN] FOUserAgent - Line 1 of a paragraph overflows the available
> area by more than 50 points. (See position 12922:1177)
> [WARN] FOUserAgent - Glyph "外" (0x5916) not available in font
> "CourierNewPSMT".
> [WARN] FOUserAgent - Line 1 of a paragraph overflows the available
> area by 3363 millipoints. (See position 14088:10230)
> [WARN] FOUserAgent - Line 1 of a paragraph overflows the available
> area by 3363 millipoints. (See position 14088:10230)
> [WARN] FOUserAgent - Line 1 of a paragraph overflows the available
> area by 3363 millipoints. (See position 14088:10230)
> [WARN] PropertyMaker - span="inherit" on fo:block, but no explicit
> value found on the parent FO.
>
> Is there a way to locate missing glyph in fo file ? I'm very like to
> see the context, and fix it by add space.
>
> ---
> Dongsheng Song
>


-- 
Regards,

The Web Maestro
-- 
 - <http://ourlil.com/>
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

Re: Issues for after the IF branch merge

[The Web Maestro]

On Mon, Feb 23, 2009 at 5:52 AM, Jeremias Maerki  
wrote:
> I'm a little hesitant to just go ahead here without more than one
> opinion. I could interpret the silence (and the +1 votes on the merge) as
> lazy assent but I'd be more comfortable with a bit more nodding. Thanks.
>
> Jeremias Maerki

This sounds like a move in a positive direction. +1 from me.

Regards,

The Web Maestro
-- 
 - <http://ourlil.com/>
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

Re: [VOTE] Merge branch for new Intermediate Format into Trunk

[The Web Maestro]

Looks interesting... +1

Clay

On 2/16/09, Jeremias Maerki  wrote:
> As mentioned earlier, I would like to start a vote for merging the
> Intermediate Format branch [1] (revision 744946) into Trunk.
>
> [1]
> https://svn.apache.org/repos/asf/xmlgraphics/fop/branches/Temp_AreaTreeNewDesign
>
> +1 from me.
>
> Jeremias Maerki
>
>


-- 
Regards,

The Web Maestro
-- 
 - <http://ourlil.com/>
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

Re: Intermediate Format Performance: Necessary changes to IFPainter interface

[The Web Maestro]

Sounds exciting! Cool!

On Tue, Feb 3, 2009 at 2:31 AM, Jeremias Maerki  wrote:
> Oh, yes, I almost forgot: I'm removing the "dy" parameter for now since
> it's not supported anyway until we support different writing-modes.
> Doesn't make sense to keep that around until then.
>
> On 03.02.2009 11:10:03 Jeremias Maerki wrote:
>> I'm getting near to finishing my work on the new intermediate format.
>> Logically, performance tests have to show whether the goals have been
>> achieved. Generally, they have:
>> - Rendering directly from the new intermediate is a lot faster than from
>> the old area tree XML format.
>> - The new intermediate files are also a lot smaller.
>> - New output formats are much easier to implement than the old Renderers.
>>
>> However, the performance tests showed that the improvement for the
>> PostScript output was rather small (and that's one of the most important
>> formats in that context). The cause was my simplistic approach to glyph
>> positioning (using the xshow operator). It causes at least one
>> DecimalFormat.format() call per glyph even if the text has no kerning,
>> letter/wordspacing or justification. So I had to revise my decision to
>> simply carry a "dx" (from SVG) property with glyph offsets. Adding SVG's
>> letter-spacing and word-spacing attributes made it possible to keep dx
>> to null in many cases. Furthermore, a custom text painting operator in
>> PostScript (similar to PDF's TJ) allowed much more compact PostScript
>> code and brought the performance back in the region of PDF and AFP.
>>
>> So, IFPainter.drawText will get two new parameters letterSpacing and
>> wordSpacing. I'm currently updating the rest of the output formats in a
>> similar way (for example, PDF gets to use the Tc operator for
>> letter-spacing). AFP will also profit from that. I'll commit when
>> everything's working again.
>>
>> I'll also publish performance figures when this is done.
>>
>> Jeremias Maerki
>>
>
>
>
>
> Jeremias Maerki
>
>



-- 
Regards,

The Web Maestro
-- 
 - <http://ourlil.com/>
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

Re: New Intermediate Format: How to handle extension attributes?

[The Web Maestro]

On Tue, Dec 23, 2008 at 5:28 AM, Jeremias Maerki  
wrote:
> 3. The IFDocumentHandler/IFPainter pair gets access to a "context"
> object where it can access to the currently applicable extension
> attributes. The context object would play adapter for the two different
> extension sources: Map from the area tree and Attributes from the
> IFParser. That would avoid any additional processing especially if no
> extension objects are present. The context object would be set on the
> IFDocumentHandler at the beginning.
>
> 4. is a variant of 3 in which case the foreign object adapter would be
> available through a ThreadLocal.
>
> Personally, I prefer option 3 as it's the easiest to understand. In this
> case, I'd probably remove set/getUserAgent() in favor of
> set/getIFContext() and provide access to the user agent through the
> IFContext to avoid cluttering the IFDocumentHandler interface.
>
> Any other opinions or additional ideas? If I hear nothing I'll implement
> option 3.

Option 3 sounds the best to me, although I don't fully comprehend the
ramifications of each choice. But does it make sense to retain the
current, deprecated set/getUserAgent() for convenience, even if it's
mapped to the set/getIFContext() method?

Happy Christmas from Park City, Utah!

Regards,

The Web Maestro
-- 
 - <http://ourlil.com/>
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

Re: [VOTE] Merge Temp_AFPGOCAResources branch into trunk

[The Web Maestro]

+1 from me!

Thanks for your hard work!

Clay

On 11/26/08, Chris Bowditch <[EMAIL PROTECTED]> wrote:
> Adrian Cumiskey wrote:
>
> Hi Adrian,
>
>> Hi Andreas,
>>
>> 2008/11/25 Andreas Delmelle <[EMAIL PROTECTED]
>> <mailto:[EMAIL PROTECTED]>>
>>
>> Adrian, just a small FWIW: Chris has drawn the right conclusion, I
>> think. No need to take any of the questions/remarks personal (even
>> though I understand this is difficult after the time you've spent on
>> perfecting the code in that branch).
>>
>>
>> Its not been so much perfecting, its been more a matter of trying to
>> clean up the mess that I inherited, trying to eliminate as much
>> copy/paste, hardcoded definitions as possible and reuse existing
>> functionality where possible without breaking anything.  This was
>> confounded by the strict binary data structure of AFP, extensive and
>> somewhat ambiguous documentation, and generally poor availability of
>> datastream analysis tools.
>
> and your efforts are appreciated even though our questions may make us
> seem ungrateful at times :)
>
>>
>> OTOH, I feel compelled to mention that attempting to kill a raised,
>> perfectly legitimate issue in an unreasonable way (by taking it to
>> be a personal offense), may alienate some people...
>>  >From a diplomatic viewpoint, not a very sound move to make right
>> before you decide to launch a vote. :/
>>
>>
>> I wasn't in anyway trying to kill the raised issue, I just chose the
>> option that I believed at the time would involve the least amount of
>> change and provide the quickest solution to the problem.  I believe now
>> that all interested parties should feel satisfied with the concluding
>> result to issue raised.
>
> Yes I am now very happy and pleased to give my +1 to this vote.
>
> Thanks,
>
> Chris
>
>
>


-- 
Regards,

The Web Maestro
-- 
<[EMAIL PROTECTED]> - <http://ourlil.com/>
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

Re: [VOTE] Merge Temp_AFPGOCAResources branch into trunk

[The Web Maestro]

Can other potential renderers take advantage of this new declaration,
or is done in an AFP-specific way?

Clay

On 11/24/08, Adrian Cumiskey <[EMAIL PROTECTED]> wrote:
> Hi Chris (and all),
>
> Chris Bowditch wrote:
>
>> Adrian,
>>
>> you've put a lot of work into the GOCA branch and it has some great
>> features, but
>>
>> There's one thing I don't like, which Jeremias points out in this thread:
>>
>> http://mail-archives.apache.org/mod_mbox/xmlgraphics-fop-dev/200811.mbox/[EMAIL
>>  PROTECTED]
>>
>>
>>
>> We currently use the PDF plugin in our software and I prefer not to
>> upgrade the plugin without knowing what the justification the interface
>> change is?
>
> Providing support for native image embedding in AFP involves providing the
> image data (in whatever
> form it may be) without any requirement for any image specific processing.
> So there is one handler
> which takes care of this in AFP, and this handler needs to declare itself
> able to support the
> handling of more than one image class.  This use case was probably not
> envisaged when the
> PDFImageHandler interface was first introduced.  Hope this explanation helps
> :).
>
> Adrian.
>


-- 
Regards,

The Web Maestro
-- 
<[EMAIL PROTECTED]> - <http://ourlil.com/>
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

Re: Updating the FOP release plan

[The Web Maestro]

On Thu, Nov 20, 2008 at 5:11 AM, Vincent Hennebert <[EMAIL PROTECTED]> wrote:

> Moreover, it can only puzzle users I think. We've used <1.0 version
> numbers for all those years, we've started a whole series of 0.9x
> releases, and all of a sudden we jump to >2.0?! With no significant
> changes from 0.95, moreover. They will wonder what is that revolution
> that they missed and that justifies such a jump.

I agree with Vincent here. I'd like to finally see a 1.0 release...
Perhaps we'll be in the minority of having a stable 1.0 release (or at
least that's the hope!)? ;-)

> The 'least worse' way to stop the <1.0 curse, IMO, is to actually call
> the next release 1.0, with the following message: the re-design branch
> has been worked on for quite some time now, it brings many new features
> and improvements compared to the old 0.20.5; it's considered stable
> enough to be used in production and 1.0 is used to acknowledge that.
>
> The work on changing IPD is likely to bring major changes to the layout
> engine, which will justify a 1.5 or 2.0 version. Once serious work has
> been done on optimization, a 2.5 or 3.0 can be released. Once
> significant features from XSL-FO 1.1 have been added, 3.5 or 4.0. And so
> on.
>
> After all, there are many open-source projects that have been around for
> years, and whose version numbers are still in 1.x or 2.x.x.

IMHO, we should finally get out of the crib, and call it fop-1.0.

Regards,

The Web Maestro
-- 
<[EMAIL PROTECTED]> - <http://ourlil.com/>
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

Re: Remove FAQ Entries Related to 0.20.5

[The Web Maestro]

On Tue, Nov 18, 2008 at 10:15 AM, Andreas Delmelle
<[EMAIL PROTECTED]> wrote:
> On 18 Nov 2008, at 12:14, Vincent Hennebert wrote:
>
>> What do you think of removing entries in the FAQ section that are
>> specific to 0.20.5 and earlier versions?
>
> Good idea. +1

Agreed... +1

> If we're going to keep the 0.20.5 tab for the moment, we may want to move
> those FAQs there so they're not completely lost (?) but I definitely don't
> see that as a must.

The Version 0.20.5 tab was removed last time we launched a
're-design'... But it's all available on archive.org:

http://web.archive.org/web/20051124163541/http://xmlgraphics.apache.org/fop/

Regards,

The Web Maestro
-- 
<[EMAIL PROTECTED]> - <http://ourlil.com/>
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

Re: Website: Areas of Expertise

[The Web Maestro]

+1 to removing it since it's not maintained...

On Thu, Jul 31, 2008 at 3:58 AM, Vincent Hennebert
<[EMAIL PROTECTED]> wrote:
> While checking the website for the 0.95 release I stumbled upon this
> "Areas of Expertise" table on the team.html page, and realised that some
> inactive committers are still listed while some active committers
> aren't. I guess those inactive committers won't mind if we replace their
> columns with active ones, but in the end I wondered: is this table
> really of any use?
>
> I mean, at the beginning of this very page it's explicitly stated that
> committers shouldn't be contacted personally, but that questions should
> be asked on the fop-users mailing list instead. Depending on the
> question the applicable committer will chime in anyway. Also, some
> committers may not have any particular area of expertise and yet be
> quite active. Should they have an empty column ;-) ?
>
> Hence my suggestion: why wouldn't we remove this table at all?
>
> Thanks,
> Vincent
>



-- 
Regards,

The Web Maestro
-- 
<[EMAIL PROTECTED]> - <http://ourlil.com/>
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

PDF format becomes ISO standard (ISO 32000-1)

[The Web Maestro]

Greetings FOP Folks,

I thought I'd let you know (in case you didn't already 'hear') that
the ISO has a new standard[1]:

  ISO 32000-1, Document management – Portable document format – Part 1: PDF 1.7

Here're some choice pieces from the article...

The Portable Document Format (PDF), undeniably one of the most
commonly used formats for electronic documents, is now accessible as
an ISO International Standard - ISO 32000-1. This move follows a
decision by Adobe Systems Incorporated, original developer and
copyright owner of the format, to relinquish control to ISO, who is
now in charge of publishing the specifications for the current version
(1.7) and for updating and developing future versions.

"By releasing the full PDF specification for ISO standardization, we
are reinforcing our commitment to openness", says Kevin Lynch, Chief
Technology Officer at Adobe. "As governments and organizations
increasingly request open formats, maintenance of the PDF
specification by an external and participatory organization will help
continue to drive innovation and expand the rich PDF ecosystem that
has evolved over the past 15 years."

...

The new standard, ISO 32000-1, Document management – Portable document
format – Part 1: PDF 1.7, is based on the PDF version 1.7 developed by
Adobe. This International Standard supplies the essential information
needed by developers of software that create PDF files (conforming
writers), software that reads existing PDF files and interprets their
contents for display and interaction (conforming readers), and PDF
products that read and/or write PDF files for a variety of other
purposes (conforming products).


Enjoy!

[1] PDF format becomes ISO standard
http://www.iso.org/iso/pressrelease.htm?refid=Ref1141

-- 
Regards,

The Web Maestro
-- 
<[EMAIL PROTECTED]> - <http://ourlil.com/>
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

Re: Preparing 0.95 final

[The Web Maestro]

I'm updating to the latest SVN now. I've had some problems building,
but I'll see if I can make it all work and test. Anything I can do on
the web front to help?

Clay

On Wed, Jun 18, 2008 at 2:10 AM, Jeremias Maerki <[EMAIL PROTECTED]> wrote:
> I think I'm done with the 0.95 branch in terms of bugfixing. Since
> especially the fix for #44412 is possibly not 100% ideal, I'll leave a
> couple of days or so for review and then start release preps.
>
> Jeremias Maerki
>
>



-- 
Regards,

The Web Maestro
-- 
<[EMAIL PROTECTED]> - <http://ourlil.com/>
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

Re: Code Quality Metrics

[The Web Maestro]

Well, Glen is the only FOP developer who's actually seen me in
person... Although Jeremias has seen my avatar... ;-)

Clay



On 6/11/08, Jeremias Maerki <[EMAIL PROTECTED]> wrote:
> ;-) I don't make assumptions what sex the people are that work with FOP
> (committer or not). In Switzerland, it's best practice to include both
> forms if you address a group of people with unknown composition.
>
> On 11.06.2008 09:44:39 Peter B. West wrote:
>> Jeremias Maerki wrote:
>> > I'm using FindBugs (as Eclipse plug-in) for some time now and it is
>> > really good. Not that I can really say yes to 100% of the suggestions.
>> > But about 98%.
>> >
>> > I'm not sure about the benefit of those reports. We've had the
>> > Checkstyle report for years now, but I doubt many people look at that
>> > often. Having those tools as IDE plug-ins is much more useful. But that
>> > needs to be set up by every dev him/herself.
>>
>> As Karen has been inactive for some time now, I can only assume that one
>> of the developers wants a sex change. Who is it?
>>
>> --
>> Peter B. West <http://cv.pbw.id.au/>
>> Folio <http://defoe.sourceforge.net/folio/>
>
>
>
>
> Jeremias Maerki
>
>

-- 
Sent from Gmail for mobile | mobile.google.com

Regards,

The Web Maestro
-- 
<[EMAIL PROTECTED]> - <http://ourlil.com/>
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

Re: Switching to Java 1.5

[The Web Maestro]

+1 from me on a new poll for discussion.

On Thu, Jun 5, 2008 at 11:56 AM, Jeremias Maerki <[EMAIL PROTECTED]> wrote:
> +1 to being cautious about dropping support for Java 1.4 without
> consulting the user base first, i.e. +1 for another user poll, though I
> wouldn't do it before October.
> +1 to putting the users' desires above the developers' desires.
> +1 to moving to Java 1.5 when the time is right.
> -0.5 (no veto) to moving to Java 1.5 before Oct 2008.
> +1 to making experiments with Retroweaver (but please not in Trunk).
>
> On 05.06.2008 17:46:07 Vincent Hennebert wrote:
>> Hi Guys,
>>
>> I would like to raise this topic again: what about switching to Java 1.5
>> as a minimum requirement?
>>
>> The End of Life transition period for Java 1.4 will end on the 30th of
>> October 2008 [1]. The next version of FOP (after 0.95) will probably not
>> have been released by this time, so we could start using 1.5 features in
>> the Trunk.
>>
>> [1] http://java.sun.com/j2se/1.4.2/download.html
>>
>> I don't particularly expect any disagreement from a developer point of
>> vue (who doesn't want to use 1.5 features?), so in the end this will
>> probably depend on the users' reactions, but I thought I'd ask for
>> opinions here first.
>>
>> According to the poll Jeremias made in October 2007 [2], only 14.3% of
>> the users would think it's a bad idea to switch to 1.5. A year later the
>> percentage will probably have further decreased.
>>
>> [2] http://wiki.apache.org/xmlgraphics/UserPollOct2007
>>
>> I guess a new poll will still be necessary. Or we could base it on lazy
>> consensus: "If you still want Java 1.4 compatibility, speak up now!".
>>
>> Anyway, even if 1.4 compatibility is still considered to be required,
>> there are tools to convert 1.5 code into 1.4 compatible one. I'm mainly
>> thinking of Retroweaver:
>> http://retroweaver.sourceforge.net/
>> It's BSD licensed, so IIC there wouldn't be any problem to distribute it
>> with FOP. Obviously it would be an (optional) compile-time dependency
>> only. I haven't personally tested it, but I'm told it's working pretty
>> well and it seems to be well maintained. Of course I'd volunteer to
>> introduce it into the build system and see how it works. FWIW, it's
>> based on the ASM library, that I've had the opportunity to play with
>> a few years ago, and what I can say is that it's a really nice, strong,
>> lightweight, easy to use library for manipulating class files.
>> http://asm.objectweb.org/
>>
>> Obviously we wouldn't switch everything to 1.5 immediately. We would do
>> it progressively, when fixing bugs or implementing new features. So it
>> should be easy to check that the conversion is working properly by
>> running the testsuite on a 1.4 jvm, before every commit. Also, we could
>> restrain ourselves to features that are directly translatable to 1.4:
>> generics, enhanced for loop, autoboxing/unboxing. Most of all we could
>> stick to using methods from the Java standard library that are also
>> available in the 1.4 version (and, for instance, not use the new
>> concurrency package for now).
>>
>> Just having the possibility to use generics would give us tremendous
>> benefits: simpler, cleaner, safer code, more easily understandable, more
>> easily maintainable, etc. I can't wait anymore to use those features.
>>
>> So, WDYT?
>> Thanks,
>> Vincent
>>
>>
>> --
>> Vincent HennebertAnyware Technologies
>> http://people.apache.org/~vhennebert http://www.anyware-tech.com
>> Apache FOP Committer FOP Development/Consulting
>
>
>
>
> Jeremias Maerki
>
>



-- 
Regards,

The Web Maestro
-- 
<[EMAIL PROTECTED]> - <http://ourlil.com/>
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

Re: svn commit: r648381 - in /xmlgraphics/fop/trunk: ./ src/java/org/apache/fop/fo/flow/table/ src/java/org/apache/fop/layoutmgr/ src/java/org/apache/fop/layoutmgr/inline/ src/java/org/apache/fop/layo

[The Web Maestro]

On Fri, Apr 18, 2008 at 12:52 PM, Simon Pepping <[EMAIL PROTECTED]> wrote:
> Easy please. Vincent has a preference. Jeremias is OK with it, but he
>  is not hot about it, so he is not going to do it. Vincent did not add
>  the new utilities, so he is not going to do it. That leaves Andreas to
>  do it, or me, or ..., or it remains undone. Fortunately, that would
>  not create a mess.
>
>  Jeremias has never been in the habit of creating a mess. Nor has
>  Vincent. But Jeremias does not code in the manner of Vincent, nor does
>  Vincent in Jeremias' style. We have to live with that diversity. FOP
>  is that sort of project. It benefits from that diversity, because the
>  project has so many diverse sides to it. But the style will never be
>  uniform. Alas?
>
>  Simon

Considering that Open Source project rely on many individuals working
together, for better or for worse (not unlike a marriage ;-), civility
and tolerance are paramount. Expression is also of great import, and
it can be tough to communicate freely via email, without
miscommunication occurring. That's why I generally take a moment
before responding if I feel my temperature rising... I also make an
effort try to send my thoughts offline to others I trust, to ensure
they're not 'too hot' and cause undue issues.

As far as this issue is concerned, this being FOSS, if someone has an
itch to scratch, they're generally free to scratch it. Like Simon
says, Jeremias doesn't feel strongly about combining/optimizing this
portion of code. IMO (and apparently Simon's & Jeremias') if Vincent
feels a need to optimize, he can either optimize or let it lie until
someone gets an urge they feel the need to scratch.

Vincent, my hope is that you won't take this as 'beat up on Vincent
week'. On the contrary, I think it's more about building community,
and I believe all of us (even those of us who mainly lurk or are
'inactive') have valuable wants and opinions. Expression is an
important part of every healthy relationship and community.

Regards,

The Web Maestro
-- 
<[EMAIL PROTECTED]> - <http://ourlil.com/>
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

Re: [VOTE] Merge Temp_ProcessingFeedback branch into Trunk

[The Web Maestro]

I'm camping in Big Sur, California, without a laptop so can't test...
But I trust your work.

+1 from me

Web Maestro Clay



On 4/5/08, Jeremias Maerki <[EMAIL PROTECTED]> wrote:
> As announced three days ago, I'd like to call for a vote to merge the
> processing feedback branch [1] into Trunk. This will add the new
> per-processing-run event subsystem to FOP that has been described on:
> http://wiki.apache.org/xmlgraphics-fop/ProcessingFeedback
>
> [1]
> https://svn.apache.org/repos/asf/xmlgraphics/fop/branches/Temp_ProcessingFeedback
>
>
> +1 from me.
>
> Jeremias Maerki
>
>


-- 
Regards,

The Web Maestro
-- 
<[EMAIL PROTECTED]> - <http://ourlil.com/>
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

Re: [VOTE] Release FOP 0.95beta (second try)

[The Web Maestro]

+1 from me... Nice work. Thanks!

BTW, I've got a couple of updates to the web site (forrest.properties
& skinconf.xml), which I'll commit when I return to my computer.

Clay



On 3/19/08, Vincent Hennebert <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> This is a vote for releasing version 0.95beta of Apache FOP, second try.
> The candidate distribution files were created from the following tag:
> https://svn.apache.org/repos/asf/xmlgraphics/fop/tags/fop-0_95beta/
> (rev. 638320). They may be found on the following page:
> http://people.apache.org/~vhennebert/fop-0_95beta/
>
> They are signed with the PGP key that was used to sign this
> message.
>
> The MD5 sums are:
> d0e36f9392bac70c1860e0509697ca5e  fop-0.95beta-bin.tar.gz
> 53819cd1645844f9f70861910d9b6208  fop-0.95beta-bin.zip
> 7a1fd579c1244d6375920b6090e10a1a  fop-0.95beta-src.tar.gz
> 67838ba5bf9d9e154859693f803885a8  fop-0.95beta-src.zip
>
> The SHA1 sums are (can be checked using 'openssl sha1'):
> 522fef09cf0182ead8d59c9193373be66e3db533  fop-0.95beta-bin.tar.gz
> ff7f68e2db55fd8b2ec2b4f5fbd8cdf2aead36cb  fop-0.95beta-bin.zip
> 25470a194427bb7a88ebf2ffb0f2bc92f7228ede  fop-0.95beta-src.tar.gz
> b981395c91e5e319d53b09853ef18bf2e3c00925  fop-0.95beta-src.zip
>
> The new website can be checked at the following address:
> http://people.apache.org/~vhennebert/fop-0_95beta/site/index.html
>
> There are still a few broken links that will need to be fixed before the
> final release, but I don't think this should further delay the release
> of the beta version. These are mainly the following ones:
> build/site/skin/images/tab-right.gif
> build/site/skin/images/tab-left.gif
> build/site/trunk/graphics.html: anchor #imageio not found
> build/site/0.95/graphics.html: anchor #imageio not found
>
> The vote will end on Saturday 22st March, 13:00 UTC.
>
> Votes only on general@ please.
>
> +1 for me.
>
> Thanks,
> Vincent Hennebert
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.6 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFH4QzroHLU0ENYxYQRAt2pAJ0ZCyqKoSWftzNbvfEF76RU/a7tvwCdGkmB
> RhrOF/xxzyoJUkZAfmofueE=
> =0fOc
> -END PGP SIGNATURE-
>

-- 
Sent from Gmail for mobile | mobile.google.com

Regards,

The Web Maestro
-- 
<[EMAIL PROTECTED]> - <http://homepage.mac.com/webmaestro/>
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

Re: Updating to a newer Forrest (was: Next release - when?)

[The Web Maestro]

I was thinking about updating the tabs to be more meaningful. Here's
what we currently have:

* Home
* Version 0.93
* Version 0.94
* FOP Trunk
* Development

And I"m thinking about changing that to:
* Home
* FOP Previous Release (0.93)
* FOP Stable Release 0.94
* FOP Trunk
* Development

We could go the 'Versioned Docs' tab route a la Forrest like this:

* Home
* Versioned Docs
   o Version 0.93
   o Version 0.94
* FOP Trunk
* Development

It would be fairly easy to do, and it doesn't require Forrest:Views
but I'm not a big fan of it myself. Then again I believe the new Quick
Start Guide will be a big help.

Any comments?

Regards,

The Web Maestro
-- 
<[EMAIL PROTECTED]> - <http://homepage.mac.com/webmaestro/>
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

Re: svn commit: r632716 - /xmlgraphics/fop/trunk/src/documentation/content/xdocs/quickstartguide.xml

[The Web Maestro]

On Sun, Mar 2, 2008 at 9:51 AM, The Web Maestro
<[EMAIL PROTECTED]> wrote:
>  On 3/2/08, Jeremias Maerki <[EMAIL PROTECTED]> wrote:
>  > Hmm, for me that already goes beyond a Quick Start Guide. Many of the
>  > listed features will only be interesting to the user once he's actually
>  > managed to take the first steps. In that case, you can easily just point
>  > him to the versioned docs index. Otherwise, we have to maintain too many
>  > duplicate links here and we probably confuse the user with a lot of
>  > details.
>  >
>  > I therefore built a counter-proposal for this page. It involves just the
>  > minimal steps to run a "Hello World!". Find it attached.

I've replaced my version with yours, improved the 'English' (even
though Jeremias is all but fluent) and fixed a few 'typos' like
'favourite' ;-)

BTW, the additions you made for Forrest were superb! Nice work!
Hopefully they'll be able to fix the little issues raised (like what
to do with table headers if there isn't a  element).

Regards,

The Web Maestro
-- 
<[EMAIL PROTECTED]> - <http://homepage.mac.com/webmaestro/>
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

Re: Supporting unusual encodings for Type 1 fonts

[The Web Maestro]

Thanks!

Clay



On 3/2/08, Jeremias Maerki <[EMAIL PROTECTED]> wrote:
> You should look for error messages from the viewers or obviously wrong
> results. I've just uploaded a PNG which show the three variants and the
> differences in between. This is the expected output (with explanations).
> Caution: the PNG is >1MB! Anyway, the output from the viewers you tested
> is obviously fine.
>
> http://people.apache.org/~jeremias/fop/type1-demo/changes-explained.png
>
> Another thing that could be tested is if copy/paste of the text into a
> Unicode-capable (!) application is possible. Adobe Acrobat seems to have
> a problem in certain cases but that's more a bug there than in FOP
> because other tools can extract the text just fine.
>
> On 02.03.2008 07:39:41 The Web Maestro wrote:
> > On Fri, Feb 29, 2008 at 7:14 AM, Jeremias Maerki <[EMAIL PROTECTED]>
> wrote:
> > > For those, who want to test PDF viewer compatibility I have a demo PDF
> > >  which demonstrates Type 1 "step 2" implemented with solution 2
> (multiple
> > >  descendant fonts with dynamic encoding build-up).
> > >
> > >  http://people.apache.org/~jeremias/fop/type1-demo/
> > >  - [1] font-type1-demo-before.pdf (revision 627678, before I added the
> AFM stuff, i.e. step 1)
> > >  - [2] font-type1-demo-step1.pdf (current FOP Trunk HEAD)
> > >  - [3] font-type1-demo-step2.pdf (my local working copy)
> >
> > I'm not sure what exactly to look for, but I've taken screenshots of
> > the 3 versions open Mac OS X 10.4.x Preview v3.0.9 & Acrobat 8.1.2:
> >
> > http://people.apache.org/~clay/fop/type1-demo/
> >
> > HTH!
> >
> > Regards,
> >
> > The Web Maestro
> > --
> > <[EMAIL PROTECTED]> - <http://homepage.mac.com/webmaestro/>
> > My religion is simple. My religion is kindness.
> > - HH The 14th Dalai Lama of Tibet
>
>
>
>
> Jeremias Maerki
>
>

-- 
Sent from Gmail for mobile | mobile.google.com

Regards,

The Web Maestro
-- 
<[EMAIL PROTECTED]> - <http://homepage.mac.com/webmaestro/>
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

Re: svn commit: r632716 - /xmlgraphics/fop/trunk/src/documentation/content/xdocs/quickstartguide.xml

[The Web Maestro]

That's great Jeremias... It's more along the lines of what I wanted
anyway. Thanks!

Clay



On 3/2/08, Jeremias Maerki <[EMAIL PROTECTED]> wrote:
> Hmm, for me that already goes beyond a Quick Start Guide. Many of the
> listed features will only be interesting to the user once he's actually
> managed to take the first steps. In that case, you can easily just point
> him to the versioned docs index. Otherwise, we have to maintain too many
> duplicate links here and we probably confuse the user with a lot of
> details.
>
> I therefore built a counter-proposal for this page. It involves just the
> minimal steps to run a "Hello World!". Find it attached.
>
> On 02.03.2008 07:42:09 clay wrote:
> > Author: clay
> > Date: Sat Mar  1 22:42:02 2008
> > New Revision: 632716
> >
> > URL: http://svn.apache.org/viewvc?rev=632716&view=rev
> > Log:
> > Adding Quick Start Guide.
>
> Jeremias Maerki
>

-- 
Sent from Gmail for mobile | mobile.google.com

Regards,

The Web Maestro
-- 
<[EMAIL PROTECTED]> - <http://homepage.mac.com/webmaestro/>
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

Re: Updating to a newer Forrest (was: Next release - when?)

[The Web Maestro]

>  > >  > I removed those links in the nav, and instead replaced them with a
>  > >  > link to a new Quick Start guide.
>  > >
>  > >  Only that Quick Start Guide is missing!?!
>  >
>  > No...
>
>  Are you really sure? http://svn.apache.org/viewvc?rev=632558&view=rev

D'oh! I'd `svn add`d it, but I wasn't using an svn co with https, so I
had to 'fix' it:

http://svn.apache.org/viewvc?view=rev&revision=632716

>  > I added a new file called 'Quick Start Guide' for the Home
>  > navigation. At present, the Quick Start Guide merely has links to the
>  > important Newbie stuff (mostly what I copied to the Nav from 0.95:
>  > Download, Build, Configure; as well as what you can do with FOP:
>  > graphics, embedding, servlets, etc.). My intention is to turn it into
>  > a 'real' Quick Start Guide.
>  >
>  > >  > >  Also, have you looked at disabling the menu auto-rolling feature? 
> If
>  > >  > >  not, I will ;-)
>  > >  >
>  > >  > Fixing that should be as easy as adding this to the bottom of the
>  > >  >  block in src/documentation/skinconf.xml:
>  > >  >
>  > >  > 
>  > >  > .menuitemgroup{ display: block;}
>  > >  > 
>  > >  >
>  > >  > I just added a change to skinconf.xml in svn. Unfortunately, the
>  > >  > change did not show in my local build. Nevertheless that's how Forrest
>  > >  > works.
>  >
>  > Did you get the .menuitemgroup CSS to work?
>
>  Haven't tried it, yet. I will later today.

Cool!

-- 
Regards,

The Web Maestro
-- 
<[EMAIL PROTECTED]> - <http://homepage.mac.com/webmaestro/>
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

Re: Supporting unusual encodings for Type 1 fonts

[The Web Maestro]

On Fri, Feb 29, 2008 at 7:14 AM, Jeremias Maerki <[EMAIL PROTECTED]> wrote:
> For those, who want to test PDF viewer compatibility I have a demo PDF
>  which demonstrates Type 1 "step 2" implemented with solution 2 (multiple
>  descendant fonts with dynamic encoding build-up).
>
>  http://people.apache.org/~jeremias/fop/type1-demo/
>  - [1] font-type1-demo-before.pdf (revision 627678, before I added the AFM 
> stuff, i.e. step 1)
>  - [2] font-type1-demo-step1.pdf (current FOP Trunk HEAD)
>  - [3] font-type1-demo-step2.pdf (my local working copy)

I'm not sure what exactly to look for, but I've taken screenshots of
the 3 versions open Mac OS X 10.4.x Preview v3.0.9 & Acrobat 8.1.2:

http://people.apache.org/~clay/fop/type1-demo/

HTH!

Regards,

The Web Maestro
-- 
<[EMAIL PROTECTED]> - <http://homepage.mac.com/webmaestro/>
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

Re: Updating to a newer Forrest (was: Next release - when?)

[The Web Maestro]

On Sat, Mar 1, 2008 at 1:53 PM, Jeremias Maerki <[EMAIL PROTECTED]> wrote:
>  Thanks, Clay! I've already fixed most problems locally. There's a
>  problem with Forrest 0.8 and trunk concerning compliance.pdf. I've
>  already submitted a patch [1] against Forrest Trunk to fix this (plus
>  some other improvements). The "knownissues-overview" problem is for
>  tomorrow. I'll upload the changes when everything is working. The new
>  PDFs will look quite nice when this is finished. Except for the missing
>  auto-table-layout support, of course. :-(
>
>  [1] https://issues.apache.org/jira/browse/FOR-1072

>  > I removed those links in the nav, and instead replaced them with a
>  > link to a new Quick Start guide.
>
>  Only that Quick Start Guide is missing!?!

No... I added a new file called 'Quick Start Guide' for the Home
navigation. At present, the Quick Start Guide merely has links to the
important Newbie stuff (mostly what I copied to the Nav from 0.95:
Download, Build, Configure; as well as what you can do with FOP:
graphics, embedding, servlets, etc.). My intention is to turn it into
a 'real' Quick Start Guide.

>  > >  Also, have you looked at disabling the menu auto-rolling feature? If
>  > >  not, I will ;-)
>  >
>  > Fixing that should be as easy as adding this to the bottom of the
>  >  block in src/documentation/skinconf.xml:
>  >
>  > 
>  > .menuitemgroup{ display: block;}
>  > 
>  >
>  > I just added a change to skinconf.xml in svn. Unfortunately, the
>  > change did not show in my local build. Nevertheless that's how Forrest
>  > works.

Did you get the .menuitemgroup CSS to work?

Regards,

The Web Maestro
-- 
<[EMAIL PROTECTED]> - <http://homepage.mac.com/webmaestro/>
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

Re: Next release - when?

[The Web Maestro]

On Fri, Feb 29, 2008 at 2:18 AM, Vincent Hennebert
<[EMAIL PROTECTED]> wrote:
>  Jeremias Maerki wrote:
>  > Looks good, Clay. Please commit it to Trunk. I'll take it from there and
>  > make sure we can incorporate this in the 0.95 release. I'll also see
>  > about switching to Forrest Trunk so we can use FOP 0.94/0.95 for the
>  > PDFs.

It's in there...

>  > On 29.02.2008 08:34:00 The Web Maestro wrote:
>  >> Howdy Folks,
>  >>
>  >> I've got an update to the FOP web site for the 0.95 release:
>  >>
>  >> http://people.apache.org/~clay/fop_refactored_0.95/
>
>  This is already looking better ;-)
>
>  >> It's not too different from before, except for the 'Using FOP 0.95' &
>  >> 'FOP 0.95 Features' menus in the nav for the Home tab, and I've
>
>  I'm not sure those entries should be added to the Home tab. Basically
>  they duplicate what's in the 0.95 tab, so that will add to the confusion
>  IMO. The Home tab should remain dedicated to general informations about
>  the project. What do others think?

I removed those links in the nav, and instead replaced them with a
link to a new Quick Start guide.

>  Also, have you looked at disabling the menu auto-rolling feature? If
>  not, I will ;-)

Fixing that should be as easy as adding this to the bottom of the
 block in src/documentation/skinconf.xml:


    .menuitemgroup{ display: block;}


I just added a change to skinconf.xml in svn. Unfortunately, the
change did not show in my local build. Nevertheless that's how Forrest
works.

-- 
Regards,

The Web Maestro
-- 
<[EMAIL PROTECTED]> - <http://homepage.mac.com/webmaestro/>
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

Re: Next release - when?

[The Web Maestro]

Howdy Folks,

I've got an update to the FOP web site for the 0.95 release:

http://people.apache.org/~clay/fop_refactored_0.95/

It's not too different from before, except for the 'Using FOP 0.95' &
'FOP 0.95 Features' menus in the nav for the Home tab, and I've
removed the 0.93 (although I haven't yet removed it from SVN). And
it's built with Forrest 0.8.

svn status
M  forrest.properties
!  src/documentation/sitemap.xmap
?  src/documentation/content/xdocs/0.95
M  src/documentation/content/xdocs/tabs.xml
M  src/documentation/content/xdocs/0.94/index.xml
M  src/documentation/content/xdocs/site.xml
M  src/documentation/content/doap.rdf

NOTE: We've still got the 0.93/ directory in there, since I haven't
taken the initiative to `svn delete` it yet.

Here're the BROKEN items from the forrest STDOUT:
X [0] knownissues.html
BROKEN: Resource not found: cocoon://knownissues-raw-fotree.xml
X [0] 0.95/releaseNotes_0.95.html
 BROKEN: 
/Users/Shared/_WebDLs/_repos/apache/xmlgraphics/fop/trunk/src/documentation/content/xdocs/0.95/releaseNotes_0.95.xml
(No such file or directory)
X [0]
0.95/knownissues_overview.htmlBROKEN:
/Users/Shared/_WebDLs/_repos/apache/xmlgraphics/fop/trunk/src/documentation/content/xdocs/0.95/knownissues_overview.xml
(No such file or directory)
X [0] 0.94/changes_0.94.html
 BROKEN: 
/Users/Shared/_WebDLs/_repos/apache/xmlgraphics/fop/trunk/src/documentation/content/xdocs/0.94/changes_0.94.xml
(No such file or directory)
X [0] /0.94/releaseNotes_0.94.html
 BROKEN: 
/Users/Shared/_WebDLs/_repos/apache/xmlgraphics/fop/trunk/src/documentation/content/xdocs/0.94/releaseNotes_0.94.xml
(No such file or directory)
X [0] /0.94/changes_0.94.html
 BROKEN: 
/Users/Shared/_WebDLs/_repos/apache/xmlgraphics/fop/trunk/src/documentation/content/xdocs/0.94/changes_0.94.xml
(No such file or directory)
X [0]
/0.95/knownissues_overview.html   BROKEN:
/Users/Shared/_WebDLs/_repos/apache/xmlgraphics/fop/trunk/src/documentation/content/xdocs/0.95/knownissues_overview.xml
(No such file or directory)
X [0] /changes.html BROKEN:
/Users/Shared/_WebDLs/_repos/apache/xmlgraphics/fop/trunk/src/documentation/content/xdocs/changes.xml
(No such file or directory)
X [0] /knownissues.html
BROKEN: Resource not found: cocoon://knownissues-raw-fotree.xml
 X [0]
/0.95/releaseNotes_0.95.html BROKEN:
/Users/Shared/_WebDLs/_repos/apache/xmlgraphics/fop/trunk/src/documentation/content/xdocs/0.95/releaseNotes_0.95.xml
(No such file or directory)
X [0] /0.95/changes_0.95.html
 BROKEN: 
/Users/Shared/_WebDLs/_repos/apache/xmlgraphics/fop/trunk/src/documentation/content/xdocs/0.95/changes_0.95.xml
(No such file or directory)
 X [0] compliance.pdf
BROKEN: internal-destination or external-destination must be specified
in basic-link
X [0] changes.html  BROKEN:
/Users/Shared/_WebDLs/_repos/apache/xmlgraphics/fop/trunk/src/documentation/content/xdocs/changes.xml
(No such file or directory)
X [0] 0.94/releaseNotes_0.94.html
 BROKEN: 
/Users/Shared/_WebDLs/_repos/apache/xmlgraphics/fop/trunk/src/documentation/content/xdocs/0.94/releaseNotes_0.94.xml
(No such file or directory)
X [0]
/0.94/knownissues_overview.html   BROKEN: Resource not found:
cocoon://knownissues-raw-fotree_0.94.xml
X [0] 0.95/changes_0.95.html
 BROKEN: 
/Users/Shared/_WebDLs/_repos/apache/xmlgraphics/fop/trunk/src/documentation/content/xdocs/0.95/changes_0.95.xml
(No such file or directory)
X [0]
0.94/knownissues_overview.htmlBROKEN: Resource not found:
cocoon://knownissues-raw-fotree_0.94.xml

-- 
Regards,

The Web Maestro
-- 
<[EMAIL PROTECTED]> - <http://homepage.mac.com/webmaestro/>
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

Re: Compliance document

[The Web Maestro]

Howdy,

On Tue, Feb 26, 2008 at 3:55 AM, Jeremias Maerki <[EMAIL PROTECTED]> wrote:
> On 26.02.2008 12:39:22 Vincent Hennebert wrote:
>  > Jeremias Maerki wrote:
>  > > Clay removed the XML file to work around a problem in Forrest in 2004. 
> The
>  > > stylesheets are indeed obsolete if the original file is deleted. You
>  > > should change the ihtml if you need to do any changes.
>  >
>  > What was the problem?
>
>  Please look in the archives or wait until Clay can answer. I don't
>  really remember.

The compliance transformation stylesheets were broken, we needed a
mechanism to add information. The .ihtml document essentially gets
passed through Forrest so you can easily edit the file with an HTML
editor (WYSIWYG if you prefer!).

>  > Any chance that it could work with Forrest 0.8? If
>  > yes, would it make sense to restore the xml file? If no, can we remove
>  > the stylesheets? Why ihtml and not simply html?
>
>  I'd prefer working off the XML file but porting back all the changes
>  into the XML since 2004 is going to be hard work!

I think of it as 'it would be nice' but it'll take a lot of work for
IMHO not that much of a gain.

>  > That allows me to jump to the next subject: Clay, have you had any
>  > chance to make progress on the transition to Forrest 0.8? If not (which
>  > is ok), could you commit you current changes to a branch, so that other
>  > people can take over the work? Thanks!
>  >
>  > Also, what's the status of plugging FOP Trunk into Forrest? From what
>  > I could find in the Forrest archive it looks like it's almost done. Will
>  > it be available in Forrest 0.8?
>
>  It's done. Everyone is happy. People from more than three projects were
>  involved to make this happen (XML Graphics, Cocoon, Forrest). Ferdinand
>  Soethe tells me there are some problems with 0.8 but trunk seems to work
>  just fine now. Since we've used the 0.7 branch until now, we could just
>  as well define that we use a particular trunk revision for the time
>  being.

I have FOP built off of 0.8, but I have issues with the links to the
generated files like release notes, changes, etc.[1] (any ideas about
those links?). In addition I need to redo my refactoring of the web
site[2]. That shouldn't take long, as I think I've got a pretty clear
direction.

As for Forrest:Views, I've spent some time trying to get forrest:views
to work, but it was largely unsuccessful. I don't believe it was ever
finished, and I believe they're moving on to using a new system for
managing 'themes' in the upcoming Forrest 0.90 release

http://forrest.apache.org/pluginDocs/plugins_0_80/org.apache.forrest.plugin.internal.dispatcher/index.html.

In any event, I think I'll focus on making the site more usable. I'll
use the ideas in the Refactoring website (was Re: Next release -
when?) thread as a guide.

[1] (search for 'forrest.validate.xdocs.excludes') for the issues...
http://people.apache.org/~clay/fop_refactored/

[2]
http://www.nabble.com/Next-release---when--td14738961.html

Regards,

The Web Maestro
-- 
<[EMAIL PROTECTED]> - <http://homepage.mac.com/webmaestro/>
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

Re: Q: What should happen when an image is not found?

[The Web Maestro]

As for size? I'd say we use whatever's specified, or default to small
if it's floating or page width.

Clay



On 2/18/08, The Web Maestro <[EMAIL PROTECTED]> wrote:
> That all sounds good. As for the extension vs. Config approach, the
> config could specify the default behavior & users could override it
> via individual fox:image-missing-behavior (or
> fox:fail-on-missing-image or something). If there's no
> @fox:[image-missing-behavior] specified, it'll do the config setting
> or log a warning if nothing specified.
>
> Clay
>
>
>
> On 2/17/08, Jeremias Maerki <[EMAIL PROTECTED]> wrote:
> > Thanks for the hint. I'll look into it.
> >
> > On 16.02.2008 14:09:27 Andreas Delmelle wrote:
> > >
> > > Hi all
> > >
> > > Reason for this question is I'm trying out a test-suite that was
> > > shared by Kumar Puppala (see a recent thread on fop-users).
> > >
> > > The image formats are the same (PNG), and they are never present.
> > >
> > > Mostly, when the images are not available, I simply see an error in
> > > the log, but the process continues nevertheless, and simply yields a
> > > result that does not include the image.
> > > Apparently, though, for some images, the formatting process crashes
> > > with a FileNotFoundException for the very same reason.
> > > (in xmlgraphics.image.loader.cache.ImageCache.needImageInfo(), when
> > > the cache is accessed through the ImageManager, from
> > > fop.render.pdf.PDFRenderer.putImage())
> > >
> > > AFAICT, this is caused by the width/height and content-width/content-
> > > height properties being explicitly specified (leads to the FNFE). If
> > > they revert to their initial values, the renderer is able to continue
> > > without having to open the file.
> > >
> > > So, small question:
> > > Wouldn't it be possible and cleaner to make the behavior more
> > > consistent? Either crash or continue with an error-message in the
> > > log, for all absent images, but not depending on whether the user
> > > specified explicit values for the image dimensions?
> > >
> > > Just wondering. Not that I have a strong preference in either
> > > direction, but I just thought it might confuse our users if they see
> > > FOP recover from the error in one case, and crash in others...
> > >
> > >
> > > Cheers
> > >
> > > Andreas
> >
> >
> >
> >
> > Jeremias Maerki
> >
> >
>
> --
> Sent from Gmail for mobile | mobile.google.com
>
> Regards,
>
> The Web Maestro
> --
> <[EMAIL PROTECTED]> - <http://homepage.mac.com/webmaestro/>
> My religion is simple. My religion is kindness.
> - HH The 14th Dalai Lama of Tibet
>

-- 
Sent from Gmail for mobile | mobile.google.com

Regards,

The Web Maestro
-- 
<[EMAIL PROTECTED]> - <http://homepage.mac.com/webmaestro/>
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

Re: Q: What should happen when an image is not found?

[The Web Maestro]

That all sounds good. As for the extension vs. Config approach, the
config could specify the default behavior & users could override it
via individual fox:image-missing-behavior (or
fox:fail-on-missing-image or something). If there's no
@fox:[image-missing-behavior] specified, it'll do the config setting
or log a warning if nothing specified.

Clay



On 2/17/08, Jeremias Maerki <[EMAIL PROTECTED]> wrote:
> Thanks for the hint. I'll look into it.
>
> On 16.02.2008 14:09:27 Andreas Delmelle wrote:
> >
> > Hi all
> >
> > Reason for this question is I'm trying out a test-suite that was
> > shared by Kumar Puppala (see a recent thread on fop-users).
> >
> > The image formats are the same (PNG), and they are never present.
> >
> > Mostly, when the images are not available, I simply see an error in
> > the log, but the process continues nevertheless, and simply yields a
> > result that does not include the image.
> > Apparently, though, for some images, the formatting process crashes
> > with a FileNotFoundException for the very same reason.
> > (in xmlgraphics.image.loader.cache.ImageCache.needImageInfo(), when
> > the cache is accessed through the ImageManager, from
> > fop.render.pdf.PDFRenderer.putImage())
> >
> > AFAICT, this is caused by the width/height and content-width/content-
> > height properties being explicitly specified (leads to the FNFE). If
> > they revert to their initial values, the renderer is able to continue
> > without having to open the file.
> >
> > So, small question:
> > Wouldn't it be possible and cleaner to make the behavior more
> > consistent? Either crash or continue with an error-message in the
> > log, for all absent images, but not depending on whether the user
> > specified explicit values for the image dimensions?
> >
> > Just wondering. Not that I have a strong preference in either
> > direction, but I just thought it might confuse our users if they see
> > FOP recover from the error in one case, and crash in others...
> >
> >
> > Cheers
> >
> > Andreas
>
>
>
>
> Jeremias Maerki
>
>

-- 
Sent from Gmail for mobile | mobile.google.com

Regards,

The Web Maestro
-- 
<[EMAIL PROTECTED]> - <http://homepage.mac.com/webmaestro/>
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

Re: Q: What should happen when an image is not found?

[The Web Maestro]

On Feb 17, 2008 10:56 AM, Max Berger <[EMAIL PROTECTED]> wrote:
> Dear FOP Devs,
>
> Am 16.02.2008 um 16:54 schrieb The Web Maestro:
> > I would think the default should be to continue (warning in
> > LOG/stdout) create an empty (blank/transparent) container the size and
> > placement of the image.
>
> +1
>
> > It would be nifty if it could be a flag in the config or CLI args
> > giving the user the choiice to fail on missing images.
>
> I think this would be a good "test case" for the new feedback
> mechanism. IMO there should be a warning by default, but the user
> should be able to configure it to fail if needed.
>
> > Clay
>
> Max Berger

Even better... In addition to a config setting, another option would
be to place it in the xsl-fo file itself (I guess in the fox:
namespace since it's probably not in the XSL-FO spec...).

Regards,

The Web Maestro
-- 
<[EMAIL PROTECTED]> - <http://homepage.mac.com/webmaestro/>
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

Re: Q: What should happen when an image is not found?

[The Web Maestro]

I would think the default should be to continue (warning in
LOG/stdout) create an empty (blank/transparent) container the size and
placement of the image.

It would be nifty if it could be a flag in the config or CLI args
giving the user the choiice to fail on missing images.

Clay



On 2/16/08, Andreas Delmelle <[EMAIL PROTECTED]> wrote:
>
> Hi all
>
> Reason for this question is I'm trying out a test-suite that was
> shared by Kumar Puppala (see a recent thread on fop-users).
>
> The image formats are the same (PNG), and they are never present.
>
> Mostly, when the images are not available, I simply see an error in
> the log, but the process continues nevertheless, and simply yields a
> result that does not include the image.
> Apparently, though, for some images, the formatting process crashes
> with a FileNotFoundException for the very same reason.
> (in xmlgraphics.image.loader.cache.ImageCache.needImageInfo(), when
> the cache is accessed through the ImageManager, from
> fop.render.pdf.PDFRenderer.putImage())
>
> AFAICT, this is caused by the width/height and content-width/content-
> height properties being explicitly specified (leads to the FNFE). If
> they revert to their initial values, the renderer is able to continue
> without having to open the file.
>
> So, small question:
> Wouldn't it be possible and cleaner to make the behavior more
> consistent? Either crash or continue with an error-message in the
> log, for all absent images, but not depending on whether the user
> specified explicit values for the image dimensions?
>
> Just wondering. Not that I have a strong preference in either
> direction, but I just thought it might confuse our users if they see
> FOP recover from the error in one case, and crash in others...
>
>
> Cheers
>
> Andreas
>

-- 
Sent from Gmail for mobile | mobile.google.com

Regards,

The Web Maestro
-- 
<[EMAIL PROTECTED]> - <http://homepage.mac.com/webmaestro/>
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

Re: Supporting unusual encodings for Type 1 fonts

[The Web Maestro]

Yes... If you build it, it will be tested... ;-) I guess I was just
trying to identify the minimum PDF viewers FOP strives to support.

As for 'cleanup', you mentioned the PS & PDF code'll be messier but it
doesn't matter much... If it doesn't matter much (e.g., it's still
valid) then I guess we're good...

Clay



On 2/15/08, Jeremias Maerki <[EMAIL PROTECTED]> wrote:
> On 14.02.2008 16:24:40 The Web Maestro wrote:
> > In addition to Acrobat 6,7,8,+, Apple QuickView & Evince, I would
> > think nice to have:
> > - Acrobat Reader 5 (last version for Mac OS 9 Classic)
> > - Apple Preview 10.4 (probably similar to QuickView)
> > - Preview for 10.3 (Panther) would be nice too...
>
> People are allowed to test with all the PDF viewers they want. I have no
> Mac so I can't test any of these.
>
> > Is it possible the PDF code for option 1 could be 'cleaned up' in the
> > future (or does it matter)?
>
> Sorry, but I don't know what you mean. What's there to clean up?
>
> > Clay
> >
> >
> >
> > On 2/13/08, Jeremias Maerki <[EMAIL PROTECTED]> wrote:
> > > Just some details what each approach will produce:
> > >
> > > #1 produces a /CIDFontType0 CIDFont [1] and a /Type0 Composite Font
> > > referencing the former.
> > >
> > > #2 produces one or more /Type1 fonts.
> > >
> > > [1] for TrueType we produce a CIDFontType2 CIDFont and a /Type0
> > > Composite font for each TrueType font. OpenOffice produces one or more
> > > /TrueType fonts for each TrueType font.
> > >
> > > #1 would always generate a CID font for simplicity. What you propose is
> > > basically a "#2a", i.e. produce a /Type1 font if the document stays
> > > within the default encoding of the font. If additional characters are
> > > used FOP would switch to CID fonts instead of producing a /Type1 font.
> > > So this needs elements from #1 and #2. Possible and probably makes sense
> > > if CID fonts work in the first place. I like it.
> > >
> > > BTW, I just found out that I have to generate a ToUnicode CMap if a
> > > Type1 font doesn't use one of the encodings that are predefined in the
> > > PDF spec. So a little more work for me there.
> > >
> > > On 13.02.2008 11:57:34 Vincent Hennebert wrote:
> > > > Hi Jeremias,
> > > >
> > > > With solution #1, if I happen to use only the glyphs from the font
> that
> > > > are available in its default encoding, will the resulting PDF be the
> > > > same as in solution #2?
> > > > What I mean is, will feature-incomplete PDF readers be able to display
> > > > it? In which case this wouldn't be that bad.
> > > >
> > > > Anyway, solution #1 also looks cleaner to me, so go for it. If that
> > > > means that I'll have to create a RFE for my favourite PDF reader, then
> > > > I'll do it ;-)
> > > >
> > > > Vincent
> > > >
> > > >
> > > > Jeremias Maerki wrote:
> > > > > I've been asked to look into the possibility to support unusual
> > > > > encodings (like Cyrillic) with Type 1 fonts. Right now we only
> support
> > > > > WinAnsiEncoding (plus special handling for Symbol and ZapfDingbats).
> > > > >
> > > > > I already have an AFM parser. The AFM parser is the precondition to
> > > > > safely support non-standard encodings as only this file contains the
> > > > > glyph list of a font.
> > > > >
> > > > > I'm now on a good way to support non-WinAnsi encodings since I can
> now
> > > > > build CodePointMapping instances from an AFM file. I then have to
> teach
> > > > > the PDF and PS renderers to make use of these special encodings.
> > > > >
> > > > > That's step 1, but it will only make the font's native encoding
> > > > > available in FOP. The number of available glyphs for a Type 1 font
> will
> > > > > still remain under 255 (typicaly under 223 as the first 32 chars are
> > > > > usually not used). To support all glyphs of a Type 1 font we need
> more
> > > > > and I found two possible ways to pursue:
> > > > >
> > > > > 1. Treat Type 1 fonts as CID fonts.
> > > > >
> > > > > + Probably the cleaner approach.
> > > > > + All glyphs are supported under one singl

Re: Supporting unusual encodings for Type 1 fonts

[The Web Maestro]

mple: The "Baskerville Cyrillic" font contains 264
> > > characters/glyphs. The default encoding only contains 221 characters. So
> > > 43 additional characters can be made available like this.
> > >
> > > I'm currently leaning towards CID fonts as it is probably the cleaner
> > > approach. Both solutions are probably pretty much the same in terms of
> > > effort. The CID approach will take more work in the PS renderer and the
> > > multi-encoding approach will make changes necessary in FOP's font
> > > library.
> > >
> > > If anyone has thoughts on this, I'd appreciate it. I'll finish the
> > > changes for supporting the default encodings and then finish the
> > > processing feedback stuff before I finish this here.
> > >
> > > Jeremias Maerki
> >
> >
> > --
> > Vincent HennebertAnyware Technologies
> > http://people.apache.org/~vhennebert http://www.anyware-tech.com
> > Apache FOP Committer FOP Development/Consulting
>
>
>
>
> Jeremias Maerki
>
>

-- 
Sent from Gmail for mobile | mobile.google.com

Regards,

The Web Maestro
-- 
<[EMAIL PROTECTED]> - <http://homepage.mac.com/webmaestro/>
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

Re: Remove deprecated methods in outer API for 0.95?

[The Web Maestro]

+1 to remove pre-0.94 deprecated methods & stuff.

Clay



On 2/14/08, Max Berger <[EMAIL PROTECTED]> wrote:
> >  >For some time now we have a number of methods in our outer API that are
> >  >deprecated. I think we should remove them now. Anyone against my doing
> >  >that as part of the preparations for the release?
>
> AFAIK it is good practice to keep a deprecated API for at least 1
> release, so I'd say +1 for anything that has been marked deprecated in
> the 0.94 release and earlier.
>
> Max
>

-- 
Sent from Gmail for mobile | mobile.google.com

Regards,

The Web Maestro
-- 
<[EMAIL PROTECTED]> - <http://homepage.mac.com/webmaestro/>
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

Re: Repository properties?

[The Web Maestro]

On Feb 12, 2008 12:59 PM, Jeremias Maerki <[EMAIL PROTECTED]> wrote:
> I agree with Andreas' comments. Go ahead.

Makes sense to me.

Regards,

The Web Maestro
-- 
<[EMAIL PROTECTED]> - <http://homepage.mac.com/webmaestro/>
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

Re: What to do with the XML JARs?

[The Web Maestro]

 of Java if they have to deal with
> different classpath requirements depending on whether they use SVG or
> not. And for building the plug-ins all the JARs will need to be there
> anyway (or downloaded via Apache Ivy).
>
>
> > > 2. Move the 4 JARs to a lib/endorsed directory and adjust our scripts to
> > > insert them into the bootclasspath which has the effect of overriding
> > > the JAXP implementation of the JVM.
> >
> > I thought the only way to override the JAXP implementation bundled with
> > the JVM was to put the jars in the lib/endorsed/ directory of the JVM
> > installation?
>
> Nono, -Xbootclasspath/p: is another.
>
> >
> > > Good:
> > > - This also makes it much clearer that these JARs are not a dependency
> > > like every other.
> > >
> > > Problems:
> > > - User might wonder why the JARs are suddenly in a different place.
> > >
> > > Open Question:
> > > - Should we start programming against JAXP 1.3 (because of the XPath
> API)?
> > > But that requires that all users install JAXP 1.3 implementations in
> > > their environments which can be problematic for older application
> > > servers (like an old WebSphere which is used in many bigger companies).
> > > I'd say we should stick to JAXP 1.2 until we can move to Java 1.5.
> > >
> > > 3. Remove the implementations but not the xml-apis.jar with the JAXP 1.3
> > > API.
> > >
> > > Good:
> > > - Allows us to use the XPath and Validation facilities.
> > >
> > > Problems:
> > > - Pre-programmed user problems because old JAXP implementations are
> > > present and people don't know how to replace them or are not allowed to
> > > replace them or it's a stability danger to the whole application server
> > > when replacing it once you figure out how to do it.
> >
> > I would also go with 1., if there is a suitable answer to my question
> > above. When releasing the 1.4 versions of FOP we can always add the
> > xml-apis.jar ourselves in the lib/ directory to be able to run the
> > tests.
>
> 1 does not seem to be possible at the moment due what you uncovered.
>
>
> Jeremias Maerki
>
>

-- 
Sent from Gmail for mobile | mobile.google.com

Regards,

The Web Maestro
-- 
<[EMAIL PROTECTED]> - <http://homepage.mac.com/webmaestro/>
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

Re: Next release - when?

[The Web Maestro]

On Jan 15, 2008 1:09 AM, Jeremias Maerki <[EMAIL PROTECTED]> wrote:
> On 14.01.2008 15:21:00 The Web Maestro wrote:
> > I'll spend some more time working on the 0.8 upgrade. I'll also look
> > into implementing 'views' for the versioned docs. I guess things have
> > changed enough between 0.93 & 0.94 so we really do need 0.93 (although
> > when 0.95 is released we should be able to omit 0.94?)...
>
> You meant: omit 0.93, right? I'd always keep the last two stable
> releases.

Yes... 0.93 is what I meant.

> > If we're going to have releases around, should we put them under
> > 'Versioned Docs' (like Forrest) or do they deserve their own tabs?
>
> I'd prefer a tab per release but if the views approach requires a single
> tab for version docs, that's fine, too.
>
> Thanks for looking into this!

I've gotten the FOP site to build with forrest-0.8, but I have a few
of broken links (mostly having to do with release notes, changes, and
known issues--see the bottom of this msg).

I also had to exclude a few files from validation:
forrest.validate.skinconf=false
..
forrest.validate.xdocs.excludes=site.xml, knownissues.xml, news.xml,
0.93/knownissues_overview.xml, 0.94/knownissues_overview.xml

(I'll look into those issues and see what I can do to fix them)

Broken links (I assume we can ignore the 0.93-specific errors):

  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  


  
  
  
  
  
  
  
  
  
  
  


-- 
Regards,

The Web Maestro
-- 
<[EMAIL PROTECTED]> - <http://homepage.mac.com/webmaestro/>
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

Re: Next release - when?

[The Web Maestro]

I'll spend some more time working on the 0.8 upgrade. I'll also look
into implementing 'views' for the versioned docs. I guess things have
changed enough between 0.93 & 0.94 so we really do need 0.93 (although
when 0.95 is released we should be able to omit 0.94?)...

If we're going to have releases around, should we put them under
'Versioned Docs' (like Forrest) or do they deserve their own tabs?

Clay



On 1/14/08, Vincent Hennebert <[EMAIL PROTECTED]> wrote:
> Hi Clay,
>
> Sorry I have to agree with Jeremias here, I think the 0.93, 0.94, Trunk
> tabs are ok. In fact the general structure of the website is more or
> less ok to me. But I think the following could be improved:
> - the skin looks a bit old now. Maybe upgrading to Forrest 0.8 (+1, BTW)
>   will improve things but anyway some work is needed in this area
>   I think. (Actually the Batik website doesn't look bad... ;-) )
>   At some point I guess we will need our own branding, rather than
>   relying on a default stylesheet.
> - the behaviour of the menu on the left is a bit annoying: having to
>   click on a sub-menu to unroll it is a pain. Every time you switch to
>   another tab then switch back to the previous one, you have to unroll
>   the menus again. That's confusing I think.
>   Example: on the Home tab, click on 'Resources', then click on the
>   'Version 0.94' tab, then go back to the 'Home' tab: you have to
>   re-click on 'Resources' to unroll it again.
>   I guess there is a parameter to disable that, and have flat menus by
>   default?
> - there should be a short 'news' sections on the home page, to show that
>   the project is alive. Currently you have to click on 'Project' to
>   unroll the menu, then on 'News'. That's two superfluous clicks ;-) We
>   could leave older news in this section, and put the most recent ones
>   on the home page.
> - many other pages could be reworked/updated/removed/merged, but the
>   previous points are the most important to me.
>
>
> Jeremias Maerki wrote:
> > Sorry to be a little late but I'm -1 on merging product documentation
> > with project documentation again. I found that VERY nice to have because
> > it gives us a cleaner structure. For me, the most important thing is to
> > be able to simplify release management which is still somewhat too
> > work-intensive. I really like how Forrest did it (although I still
> > haven't checked how. I think they do something with views) and they do
> > publish versioned docs. I like keeping the difference between Trunk and
> > the latest stable release especially since we don't do releases every
> > two or three months. It produces less confusion if we add new features
> > in Trunk for those who use the latest release.
> >
> > +1 to switching to Forrest 0.8.
>
> 
>
> Vincent
>
>
> --
> Vincent HennebertAnyware Technologies
> http://people.apache.org/~vhennebert http://www.anyware-tech.com
> Apache FOP Committer FOP Development/Consulting
>

-- 
Sent from Gmail for mobile | mobile.google.com

Regards,

The Web Maestro
-- 
<[EMAIL PROTECTED]> - <http://homepage.mac.com/webmaestro/>
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

Re: Next release - when?

[The Web Maestro]

On Jan 12, 2008 8:42 AM, The Web Maestro <[EMAIL PROTECTED]> wrote:
> On Jan 11, 2008 2:28 AM, Vincent Hennebert wrote:
> > Refactoring the website? I've already been told several times that it
> > was difficult to find its way on it. Last time I mainly rephrased a few
> > sentences and removed broken links, but didn't do much more. And
> > I didn't even touch the 'Development' tab which is progressively
> > becoming out-of-date.
> >
> > Should I add that this is not a trivial task and that I'll have no time
> > for that in the next couple of months? :-P
>
> I'd be happy to help with the web site. It's not perfectly clear to me
> what else it needs, but I have some ideas. In a nutshell, 'Home'
> should include 'user' related general stuff (all the stuff it has,
> plus using FOP, upgrading, running, etc.--all the content from Version
> 0.94). The Develop should contain all that it has, plus any 'FOP
> Trunk' specific stuff. I don't what that is ATM... on first glance the
> nav for 'Version 0.94' and 'FOP Trunk' are identical nav (except
> V-0.94 has Release Notes, Changes & Known Issues).
>
> I imagine a good start would be to remove all tabs except for 'Home'
> and 'Development'
> - 'Version 0.93' just goes away
> - 'Version Trunk' content moves to 'Home'
> - I think 'FOP 0.94' just goes away. I don't see anything different
> between the nav links in the 'FOP Trunk' and 'Version 0.94' tabs--if
> there is, that content should move to 'Development'. I'll run `diff`
> on the fop/0.94/ and fop/trunk/ directories to see what's different.
> If anyone has an specific ideas on what's different, that'd help
> greatly.
>
> We could retain the 'Home', 'Version xxx', 'FOP Trunk', 'Development'
> tab structure, but I think less tabs may be better now that we've
> retired 'Version 0.20.5', during which time, I believe the multiple
> tab structure was necessary.

Here's my first stab at a refactored FOP site:

http://people.apache.org/~clay/fop_refactored/

Of course, I'm open to suggestions.

In a nutshell, here's what I did:
- rm -R 0.93/
- rm -R 0.94/
- mv trunk/* ../
- modify site.xml
- change links to /0.94/* & /trunk/* to /*
- check for broken links

I'll likely need to do the above again when we're ready to deploy.
Notice, I didn't do an `svn delete` on any of the above, since I'm
hoping for feedback first. I'll likely do the SVN equivalents to the
above when we're ready for primetime. If that time is now, I could do
it fairly quickly.

I'm also considering updating the Forrest build process to use Forrest
0.8 instead of Forrest 0.7.

If anyone's interested, here're zip'd versions of the site.xml & tabs.xml files:
http://people.apache.org/~clay/fop_refactored/site.xml.zip
http://people.apache.org/~clay/fop_refactored/tabs.xml.zip

Web Maestro Clay
-- 
Regards,

The Web Maestro
-- 
<[EMAIL PROTECTED]> - <http://homepage.mac.com/webmaestro/>
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

Re: Next release - when?

[The Web Maestro]

On Jan 11, 2008 2:28 AM, Vincent Hennebert
<[EMAIL PROTECTED]> wrote:
> Jeremias Maerki wrote:
> > I think we should start to plan the next release. How about targeting
> > the end of February or beginning of March?
>
> Seems good.
>
> > Without much thinking, the following items are on the table:
> > - Stabilizing tables.
> > - Stabilizing the image package once I've merged the brach into trunk.
> > - Verifying the AFP output works correctly.
> >
> > What else?
>
> Refactoring the website? I've already been told several times that it
> was difficult to find its way on it. Last time I mainly rephrased a few
> sentences and removed broken links, but didn't do much more. And
> I didn't even touch the 'Development' tab which is progressively
> becoming out-of-date.
>
> Should I add that this is not a trivial task and that I'll have no time
> for that in the next couple of months? :-P

I'd be happy to help with the web site. It's not perfectly clear to me
what else it needs, but I have some ideas. In a nutshell, 'Home'
should include 'user' related general stuff (all the stuff it has,
plus using FOP, upgrading, running, etc.--all the content from Version
0.94). The Develop should contain all that it has, plus any 'FOP
Trunk' specific stuff. I don't what that is ATM... on first glance the
nav for 'Version 0.94' and 'FOP Trunk' are identical nav (except
V-0.94 has Release Notes, Changes & Known Issues).

I imagine a good start would be to remove all tabs except for 'Home'
and 'Development'
- 'Version 0.93' just goes away
- 'Version Trunk' content moves to 'Home'
- I think 'FOP 0.94' just goes away. I don't see anything different
between the nav links in the 'FOP Trunk' and 'Version 0.94' tabs--if
there is, that content should move to 'Development'. I'll run `diff`
on the fop/0.94/ and fop/trunk/ directories to see what's different.
If anyone has an specific ideas on what's different, that'd help
greatly.

We could retain the 'Home', 'Version xxx', 'FOP Trunk', 'Development'
tab structure, but I think less tabs may be better now that we've
retired 'Version 0.20.5', during which time, I believe the multiple
tab structure was necessary.

Of course, there's likely to be content updates, as well as minor nav
changes needed (Changes, Release Notes, Known Issues), but that should
already be in 'FOP Trunk' content.

If anyone else has ideas, I'm open to them.

> I was also thinking about making this a beta release. With the major
> changes that we made we can't be sure that no regression has been
> introduced as well. The 0.94 release taught me that even if many bugs
> were fixed, users will stumble upon regressions and (rightly) complain
> about them.
>
> So, what about a 0.95 beta?
>
> Vincent

Like Chris, I think appending 'rc' as in fop-0.95rc would be better than 'beta'.
-- 
Regards,

The Web Maestro
-- 
<[EMAIL PROTECTED]> - <http://homepage.mac.com/webmaestro/>
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

Re: [PROPOSAL] multi-page image extension for FOP

[The Web Maestro]

On 12/20/07, Jeremias Maerki <[EMAIL PROTECTED]> wrote:
> I've been playing with the idea for some time and the time has come to
> bring this up. I would like to write an FO extension which allows to
> insert a multi-page document into an FO document, so each page produces
> a new page of exactly the same dimensions as the bitmap image in the
> final format (by default). With fo:external-graphic it's only possible
> to embed one single image somewhere inline. Of course, it's possible to
> position the fo:external-graphic so it takes up the whole page and you
> can even address individual pages (#page=3) with the new image
> package but you'd still need to know at least the number of pages at
> XSLT time to get this right. Instead, I'd like to do this with a single
> extension element on the same level as fo:page-sequence. I've called it
> fox:external-document for now. Here's the proposed specification:



> While writing this it occurred to me that this could also be implemented
> as an FO-preprocessor (SAX filter). However, since this proprocessor
> would have to generate page masters depending on the images which have
> to be inserted at the beginning of the FO file, this could be
> inefficient. The only benefits I see is that it could be used with other
> FO implementations, too, and that it wouldn't add code to FOP which has
> to be maintained. So, I would prefer to implement this as a layout
> manager.
>
> I know this is again something that doesn't really bring FOP closer to
> version 1.0. Again, it's simply coming from people using FOP on a
> day-to-day basis.
>
> WDYT?
>
> Jeremias Maerki

Looks interesting... I recall wishing 0.20.5 had something like this
back in the day. +1 from me.

-- 
Regards,

The Web Maestro
-- 
<[EMAIL PROTECTED]> - <http://homepage.mac.com/webmaestro/>
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

Re: [VOTE] Max Berger for Committer

[The Web Maestro]

On 10/26/07, Adrian Cumiskey <[EMAIL PROTECTED]> wrote:
> Well deserved Max, keep up the good work.  Unfortunately being non-pmc my
> vote won´t count - but a big thumbs up (+1) from me :).
>
>  Adrian.

Agreed. Well deserved honor being bestowed on you both (premature,
since the VOTE hasn't closed yet, but I have faith!).

While it may be true that 'technically' non-PMC VOTEs don't 'count',
it is important for the PMC to know where you stand on all votes.

I might add, that while only PMC members have binding VOTEs, IMHO,
it's important for the PMC to have a glimpse at the community
'consensus' as well.

Web Maestro Clay

-- 
Regards,

The Web Maestro
-- 
<[EMAIL PROTECTED]> - <http://homepage.mac.com/webmaestro/>
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

Re: [VOTE] Adrian Cumiskey for Committer

[The Web Maestro]

On 10/10/07, Chris Bowditch <[EMAIL PROTECTED]> wrote:
> I feel the time has come to promote Adrian to committer status.
>
> Well done Adrian! Keep up the good work!

+1 from me...  Welcome!

-- 
Regards,

The Web Maestro
-- 
<[EMAIL PROTECTED]> - <http://homepage.mac.com/webmaestro/>
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

Re: Help Refactoring the Website

[The Web Maestro]

BTW, I added a table column for 0.94 to the Compliance page. I did
*not* remove the 0.20.5 or 0.93 columns. Those can be removed fairly
easily, if decided, but I figured we might want to keep those (but add
a note that fop-0.20.5 is unsupported).

Web Maestro Clay

-- 
Regards,

The Web Maestro
-- 
<[EMAIL PROTECTED]> - <http://homepage.mac.com/webmaestro/>
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

Re: svn commit: r562332 - /xmlgraphics/fop/branches/fop-0_94/src/documentation/skinconf.xml

[The Web Maestro]

Whoop! I submitted my comments for the Compliance page instead of the
Forrest skinconf.xml file. The changes involved enabling a link to the
XML, adding an image to all external link references, enabling
COMPLIANCE badges w links to HTML & CSS, and enabling the Font
Adjustment JavaScript.

-- 
Regards,

The Web Maestro
-- 
<[EMAIL PROTECTED]> - <http://homepage.mac.com/webmaestro/>
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

Re: Help Refactoring the Website

[The Web Maestro]

On 8/2/07, Vincent Hennebert <[EMAIL PROTECTED]> wrote:
> >> Strangely enough when I run Forrest on my local copy I get different
> >> (smaller) font sizes than on the website for all the other elements but
> >> the main text (without the above change). The screen.css style sheets
> >> are exactly the same though. I wonder what might be happening?
> >
> > Can you upload the `forrest` output to your web space, so we can take
> > a look? Here's the result of mine from last night (without the
> > #content changes):
> >
> > http://people.apache.org/~clay/fop-0.94/
>
> Here it is:
> http://people.apache.org/~vhennebert/fop-0.94/

The content appears to be *exactly* the same size, but the font-size
for the tabs appears to be smaller in our versions.

> 
> > I wonder if it has to do with your browser setup (what are you
> > using--browser/version, OS/version w service packs, build etc.)? Have
> > you tried on another machine? Maybe Forrest needs to have a support
> > ticket put in about the font resize buttons (and if you prefer the
> > font-size as well).
>
> Firefox 2.0.0.5
> Ubuntu Feisty
> Revision 556027 of Forrest 0.7 but no CSS file got modified when
> I updated my copy (only Java code).
>
> I think I'm becoming crazy. On your version the main text is smaller
> than on mine (without applying the CSS change), which now has normal
> size. For all other text objects (menu, etc.), sizes are the same.

If I were feeling 'feisty' I might say something pithy, like 'You
probably are going crazy...' but I'm not so I'll tell you that the
reason our sites didn't have the font-size adjust buttons was because
they weren't enabled in 'src/documentation/skinconf.xml'. I just
enabled it, as well as:
- compliance links (shows HTML & CSS compliance badges)
- external-link-image (indicates off-site links with mini-image icon)
- and XML file availability (enables re-purposing of content via XML)

> Trying with Konqueror the main text is larger on my version, but also
> the tab titles (Home, Version 0.93, etc.).
>
> I have no font-size button on any version, with any browser. Note that
> I have them on the XML Graphics site.

Mentioning that it was on the XML Graphics site gave me the clue it
was a preference setting.

> !?!??
> Thanks for looking into this,
> Vincent

Glad I could help... It's been a while since I've delved into Forrest.
In fact, they just released Forrest 0.8, so someone may want to look
into identifying if there's a compelling reason to 'upgrade'. ;-)

-- 
Regards,

The Web Maestro
-- 
<[EMAIL PROTECTED]> - <http://homepage.mac.com/webmaestro/>
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

Re: Help Refactoring the Website

[The Web Maestro]

Hi Vincent,

On 8/2/07, Vincent Hennebert <[EMAIL PROTECTED]> wrote:
> The Web Maestro a écrit :
> > On 7/31/07, Vincent Hennebert wrote:
> >> As I said I already did it, but if you wanna double-check all the
> >> better. Also, one thing that would be great if you could have a look at,
> >> is improving the stylesheet a bit. For example the main content is set
> >> to be displayed at 80% of its size. That should really not be the case
> >> as the setting for the main text's size should be left to the user's
> >> choice (I'm ok with reducing the size of e.g. the menu, however). I'm
> >> not really sure where to change that as the CSS stylesheets seem to
> >> directly come from the Forrest distribution.
> >
> > I haven't had a chance to work on the font-size yet, but here're a
> > couple of links to get started on it if I can't get to it in time:
> >
> > http://forrest.apache.org/docs_0_70/your-project.html#skins
> >
> > http://forrest.apache.org/docs_0_70/skin-package.html
> >
> > FWIW, I tried modifying the
> > 'branches/fop-0_94/src/documentation/skinconf.xml' file, but it didn't
> > work. I added the 'p, td, li' declaration to adjust it and make it
> > larger. I didn't commit my change.
>
> Thanks for the pointers. By adding the following in skinconf.xml:
> #content { font-size: 100% }
> I managed to get normal size for the main text. I didn't commit the
> change because I wasn't sure this was the right place to do that.

That's perfect. Go ahead and commit...

> Strangely enough when I run Forrest on my local copy I get different
> (smaller) font sizes than on the website for all the other elements but
> the main text (without the above change). The screen.css style sheets
> are exactly the same though. I wonder what might be happening?

Can you upload the `forrest` output to your web space, so we can take
a look? Here's the result of mine from last night (without the
#content changes):

http://people.apache.org/~clay/fop-0.94/

> > Here are a few locations for the Forrest skin files if you want to
> > modify them (although the CSS change may be overwritten if someone
> > else changes it (hence it'd be better to find a 'skinconf.xml'
> > solution):
> >
> > apache-forrest-0.7/main/webapp/skins/pelt/css/profile.css.xslt
> > fop/trunk/build/site/skin/profile.css
> > fop/trunk/build/site/skin/profile.css.xslt
> >
> > However, I think it's somewhat of a 'moot' point, as in the upper
> > right of the page, there are increase and decrease font-size widget
> > buttons, and the settings appear to follow you from page to page...
>
> Still, the user shouldn't have to do anything to retrieve their favorite
> text size. That's a basic accessibility rule IMHO.
> Moreover, I don't get any font-size widget button, again both on my
> local copy and the website!? FWIW I'm using the Trunk of the 0.7 branch.

I wonder if it has to do with your browser setup (what are you
using--browser/version, OS/version w service packs, build etc.)? Have
you tried on another machine? Maybe Forrest needs to have a support
ticket put in about the font resize buttons (and if you prefer the
font-size as well).

> 
>
> Vincent

-- 
Regards,

The Web Maestro
-- 
<[EMAIL PROTECTED]> - <http://homepage.mac.com/webmaestro/>
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

Re: Help Refactoring the Website

[The Web Maestro]

On 7/31/07, Vincent Hennebert <[EMAIL PROTECTED]> wrote:
> Hi Clay,
>
> Thanks for chiming in!

I've committed my changes, so the site should be re-factored. There is
likely a bunch of content in the '0.94' realm that needs updating so
it's more relevant to the current release. In addition, there may be
some pages, which will need some attention (like
'branches/fop-0_94/build/site/0.94/releaseNotes_0.94.html',
'branches/fop-0_94/build/site/0.94/changes_0.94.html' and
'branches/fop-0_94/build/site/0.94/knownissues_overview.html').

> > It didn't take too much to re-factor the site... Just had to adjust
> > the tabs.xml and site.xml documents (and remove the 0.20.5 documents).
> > I'll need to do a `svn delete` for the 0.20.5/ and 0.93/ directories,
> > so let me know if I should do that NOW, or we need to wait until we're
> > more ready for the release.
>
> As I said I already did it, but if you wanna double-check all the
> better. Also, one thing that would be great if you could have a look at,
> is improving the stylesheet a bit. For example the main content is set
> to be displayed at 80% of its size. That should really not be the case
> as the setting for the main text's size should be left to the user's
> choice (I'm ok with reducing the size of e.g. the menu, however). I'm
> not really sure where to change that as the CSS stylesheets seem to
> directly come from the Forrest distribution.

I haven't had a chance to work on the font-size yet, but here're a
couple of links to get started on it if I can't get to it in time:

http://forrest.apache.org/docs_0_70/your-project.html#skins

http://forrest.apache.org/docs_0_70/skin-package.html

FWIW, I tried modifying the
'branches/fop-0_94/src/documentation/skinconf.xml' file, but it didn't
work. I added the 'p, td, li' declaration to adjust it and make it
larger. I didn't commit my change.

Here are a few locations for the Forrest skin files if you want to
modify them (although the CSS change may be overwritten if someone
else changes it (hence it'd be better to find a 'skinconf.xml'
solution):

apache-forrest-0.7/main/webapp/skins/pelt/css/profile.css.xslt
fop/trunk/build/site/skin/profile.css
fop/trunk/build/site/skin/profile.css.xslt

However, I think it's somewhat of a 'moot' point, as in the upper
right of the page, there are increase and decrease font-size widget
buttons, and the settings appear to follow you from page to page...

Here's the snippet,

  
  

p, td, li {
  font-size: 94%;
}
p.quote {
  margin-left: 2em;
  padding: .5em;
  background-color: #f0f0f0;
  font-family: monospace;
}
.yes { background-color: #99FF99; }
.no  { background-color: #FF; }
.partial { background-color: #CC; }
.ForrestTable td.basic  { text-align: center; }
.ForrestTable td.extended   { text-align: center; }
.ForrestTable td.complete   { text-align: center; }
.ForrestTable td.na { text-align: center; }
.ForrestTable td.yes{ background-color: #99FF99;
text-align: center; }
.ForrestTable td.no { background-color: #FF;
text-align: center; }
.ForrestTable td.partial{ background-color: #CC;
text-align: center; }
.ForrestTable td.category   { /*background-color: #CFDCED;*/
   font-size: 1.2em }

  

Web Maestro Clay

-- 
Regards,

The Web Maestro
-- 
<[EMAIL PROTECTED]> - <http://homepage.mac.com/webmaestro/>
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

Re: Help Refactoring the Website

[The Web Maestro]

On 7/30/07, The Web Maestro <[EMAIL PROTECTED]> wrote:
> Thanks Chris! I'll look into what I can to help re-factor the site to
> remove the 0.20.5 references. I agree, that with 0.93 & 0.94, the 0.20
> branch information is no longer necessary.

I was able to factor out the 0.20.5 stuff but there are a couple of
relatively minor issues:

1. I am planning to remove 0.93, but want to confirm this should be
removed so we have only 0.94 and trunk ( as well as Trunk, etc.)
2. To create the '0.94' section, I copied the 'Trunk' area, but there
are numerous areas in the documentation which are likely outdated.
Should I commit my changes and let others adjust the documentation to
reflect the recent changes to the code?
3. There are a few places where a 'date' will be required to identify
when 0.94 is released, but I'm not sure what that date is yet.

It didn't take too much to re-factor the site... Just had to adjust
the tabs.xml and site.xml documents (and remove the 0.20.5 documents).
I'll need to do a `svn delete` for the 0.20.5/ and 0.93/ directories,
so let me know if I should do that NOW, or we need to wait until we're
more ready for the release.

Web Maestro Clay

-- 
Regards,

The Web Maestro
-- 
<[EMAIL PROTECTED]> - <http://homepage.mac.com/webmaestro/>
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

Re: Help Refactoring the Website

[The Web Maestro]

On 7/30/07, Chris Bowditch <[EMAIL PROTECTED]> wrote:
> Hi Clay,
>
> 0.93 and 0.94 are still compatible with Java 1.3 so AIX 4.1 users will
> still be able to use it. We have clients running AIX who use Java 1.4,
> so I didn't realise AIX couldn't run 1.4. Maybe its down to exact o/s
> version. In either case, we decided to drop support for 1.3 after 0.94.
> So if 1.3 is still needed in the future users can download 0.94. And I
> think the website should reflect this.
>
> The reason why 0.20.5 should be removed from the website is that
> fop-users is still receiving several posts per week relating to it.
> There is now very little knowledge of it within our development team, so
> supporting it is not something we would like to continue. Therefore,
> users should be actively discouraged from downloading it. Looking at the
> website today, I get the impression that 0.20.5 and 0.94 are two
> separate development streams which both receive active maintenance.
> However, we all know that is not the case. 0.9x is a direct replacement
> for the 0.20.x series.
>
> It made sense to keep 0.20.5 on the website for a couple of years after
> the initial 0.9x release to give folk a chance to upgrade. But 0.9x has
> been around for a couple of years and now I believe it is time to start
> encouraging users to switch over.
>
> Chris

Thanks Chris! I'll look into what I can to help re-factor the site to
remove the 0.20.5 references. I agree, that with 0.93 & 0.94, the 0.20
branch information is no longer necessary.

Web Maestro Clay
-- 
Regards,

The Web Maestro
-- 
<[EMAIL PROTECTED]> - <http://homepage.mac.com/webmaestro/>
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

Re: Help Refactoring the Website

[The Web Maestro]

On 7/29/07, Andreas L Delmelle <[EMAIL PROTECTED]> wrote:
> On Jul 27, 2007, at 18:36, Andreas L Delmelle wrote:
> >> it would be good to refactor
> >> the website before the release and, in particular, remove the 0.20.5
> >> tab.
>
> This could maybe still be done before the release, but I started
> wondering...
>
> >> I'd like to call for help on this, as this is not a small task.
> >> I'll try to do as much as possible on the WE, but that would be
> >> great if
> >> we could share the work. Any volunteers?
> >> Some tasks I can think of right now:
> >> - update the introduction page (latest stable release, version of the
> >>   recommendation implemented...)
> >> - add a small news section on the home page? this would make the site
> >>   look more live. It could simply list the latest versions released.
> >> - correct/update/simplify other pages
>
> Wouldn't it be better, FTM, to focus on making the site 0.94-ready,
> and do any serious restyling afterwards? It's just that a release by
> itself already takes some work and preparation... Just a thought.

I'll spend some time looking into what it'll take to refactor,
although I agree with Andreas that it would be better to focus on
getting 0.94 ready and do any necessary 'purging' of fop-0.20.5 after
that, if that's what's deemed best.

I'm not actually convinced eradicating it from the FOP site is the
best route, as there will be some who can't upgrade (namely users of
AIX 4.1 and/or others who can't upgrade to a Java Run-time Environment
newer than 1.3)... I would think the fop-0.20.5 information should
remain accessible somewhere other than on <http://archive.org/>. The
good part is, that the content will likely never change and would
exist on a separate TAB, out of the way. That's not to say I'm firmly
in the trench of keeping the content, but I don't see how it'd hurt to
retain it.

-- 
Regards,

The Web Maestro
-- 
<[EMAIL PROTECTED]> - <http://homepage.mac.com/webmaestro/>
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

Re: Row backgrounds vs table background

[The Web Maestro]

On 6/29/07, Jeremias Maerki <[EMAIL PROTECTED]> wrote:


On 29.06.2007 14:07:51 Pascal Sancho wrote:
> 2/ XSLFO 6.7.9 says that fo:table-row "does not generate any areas".
>
> My question is: how to display row background if there is no area for it?

It's fo:table (6.7.3) that generates the areas for its children. See the
section there:

"The areas generated and returned by the fo:table formatting object have
as children:
• Areas, with only background, corresponding to the table-header, table-footer, 
table-body, spanned
columns, columns, and rows.
The spanned columns (fo:table-column with a "number-columns-spanned"
value greater than 1) are used
in the same way as the "column groups" in CSS2 for determining the background. ☞
• Areas returned by the fo:table-cell formatting objects."


The above would indicate to me that the linked 'lower-left' version
exhibits how FOP should display table-row backgrounds.

NOTE: In the linked screenshot, the original 'lower-left' quadrant was
moved to the right, as
IMO, it more closely relates to the upper-right quadrant.

Linked table-row graphic:
http://www.ourlil.com/friends/apache/fop/table-row_backgrounds2.png

Re: update 0.20 and 0.93 xdocs index pages?

[The Web Maestro]

On 6/7/07, Adrian Cumiskey <[EMAIL PROTECTED]> wrote:

I have attached a patch file to update the descriptions to something
which maybe better communicates to potential new FOP users which version
of FOP we recommend they adopt in their environments.  Please feel free
of course to amend these descriptions, I have provided them just for
illustration.

Adrian.


Patch applied. The change will show up on the site after the next site
generation. Thank you Adrian.

Web Maestro Clay

--
Regards,

The Web Maestro
--
<[EMAIL PROTECTED]> - <http://homepage.mac.com/webmaestro/>
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

Re: Comments on the AFP output

[The Web Maestro]

Thanks for the update, Jeremias! Hearing that our AFP Renderer is so
well-received is great news!

Web Maestro Clay

--
Regards,

The Web Maestro
--
<[EMAIL PROTECTED]> - <http://homepage.mac.com/webmaestro/>
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

Re: Destinations (was: Re: svn commit: r525078...)

[The Web Maestro]

Hi All,

On 4/7/07, Andreas L Delmelle <[EMAIL PROTECTED]> wrote:

Could be a problem with either the browser or the plugin. Works fine
if you use Safari and Adobe Reader 8.

Cheers,

Andreas


Agreed. It works in Safari 2.0.4 (via Adobe Reader Plugin) under Mac
OS X 10.4.9. Thanks for the clarification, Andreas!

However, the fact that it didn't work under Firefox (via Shubert's PDF
Browser plugin 2.0.1). I tried it again after updating to a newer
version of the PDF Browser Plugin (v2.2.3) and it works great!

Nice work, Jay!

Web Maestro Clay

--
Regards,

The Web Maestro
--
<[EMAIL PROTECTED]> - <http://homepage.mac.com/webmaestro/>
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

Re: Destinations (was: Re: svn commit: r525078...)

[The Web Maestro]

It didn't work for me (Mozilla 2.0.0.3; Mac OS X 10.4.9). I want it to! :-)

On 4/6/07, Jay Bryant <[EMAIL PROTECTED]> wrote:

That was right. I have corrected it by making the following change to
org.apache.fop.render.pdf.PDFRenderer: When the renderer processes a
PDFDestination, it adds a PDFGoTo and makes the PDFDestination refer to the
GoTo object.

I've tested it on my web site. If you want to see it work, go to
http://www.bryantcs.com/fop/test, open link-test.pdf, and click "Link test"
(the only text on the page). It opens test.pdf to the second page because
the destination named block2 is on the second page.

Jay Bryant
Bryant Communication Services


--
Regards,

The Web Maestro
--
<[EMAIL PROTECTED]> - <http://homepage.mac.com/webmaestro/>
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

Re: Welcome Jay!

[The Web Maestro]

Welcome Jay! Congratulations! I believe I speak for all of us when I
say we're all available if you have any questions or need anything.

And thanks for finalizing the set-up, Jeremias!

Web Maestro Clay

On 2/28/07, Jeremias Maerki <[EMAIL PROTECTED]> wrote:

Welcome, Jay, as new committer of Apache FOP!


--
Regards,

The Web Maestro
--
<[EMAIL PROTECTED]> - <http://homepage.mac.com/webmaestro/>
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

Re: [VOTE] Jay Bryant as new committer

[The Web Maestro]

Jay et al,

I'll be following up with some administrative stuff shortly. We need
to get your CLA so we can give you write access to the XML Graphics
repositories:

http://www.apache.org/licenses/#clas

Web Maestro Clay

On 1/27/07, The Web Maestro <[EMAIL PROTECTED]> wrote:

On 1/23/07, The Web Maestro <[EMAIL PROTECTED]> wrote:
> I'd like to propose Jay as an XML Graphics committer (FOP working
> set). I believe he will be a solid addition to our work force.

All members of the Apache XML Graphics Project Management Committee
voted. There were 10 positive votes, 0 negative votes and no other
votes.

Congratulations, Jay! And welcome to the team.

Here's a good link for you to peruse, if you haven't already done so:

http://www.apache.org/dev/#committers

--
Regards,

The Web Maestro
--
<[EMAIL PROTECTED]> - <http://homepage.mac.com/webmaestro/>
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet




--
Regards,

The Web Maestro
--
<[EMAIL PROTECTED]> - <http://homepage.mac.com/webmaestro/>
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

Re: [VOTE] Jay Bryant as new committer

[The Web Maestro]

On 1/23/07, The Web Maestro <[EMAIL PROTECTED]> wrote:

I'd like to propose Jay as an XML Graphics committer (FOP working
set). I believe he will be a solid addition to our work force.


All members of the Apache XML Graphics Project Management Committee
voted. There were 10 positive votes, 0 negative votes and no other
votes.

Congratulations, Jay! And welcome to the team.

Here's a good link for you to peruse, if you haven't already done so:

http://www.apache.org/dev/#committers

--
Regards,

The Web Maestro
--
<[EMAIL PROTECTED]> - <http://homepage.mac.com/webmaestro/>
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

Re: Increase in activity?

[The Web Maestro]

I agree. I suspect it's a function of what I call 'If you release it,
they will come.'

:-D

On 1/24/07, Chris Bowditch <[EMAIL PROTECTED]> wrote:

Jeremias Maerki wrote:

> Do I have a slightly distorted perception or do we currently see an
> increase in activity, even patches, following the 0.93 release?

Hi Jeremias,

yes I think there has been a increase in both user and development
activity in the few weeks since the New Year. Maybe as a result of the
recent stable release.

Chris







--
Regards,

The Web Maestro
--
<[EMAIL PROTECTED]> - <http://homepage.mac.com/webmaestro/>
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

[VOTE] Jay Bryant as new committer

[The Web Maestro]

Howdy folks,

Jay Bryant has been an active member of the Apache XML Graphics
Project's fop-users@ and fop-dev@ communities for the last few years.

Aside from frequently answering newbie questions, he also submits
actual xsl-fo code to help. I'm also excited to note, that Jay
recently posted a note showing a desire to add Named Destinations for
all IDs [1]!

I'd like to propose Jay as an XML Graphics committer (FOP working
set). I believe he will be a solid addition to our work force.

Votes only on general@xmlgraphics.apache.org please.

+1 from me.

[1]
http://www.nabble.com/Adding-Named-Destinations-for-all-IDs-tf3078009.html

--
Regards,

The Web Maestro
--
<[EMAIL PROTECTED]> - <http://homepage.mac.com/webmaestro/>
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

Re: Wrong link to source download site

[The Web Maestro]

On 1/10/07, Yannick Valot <[EMAIL PROTECTED]> wrote:

Trouble is, http://www.apache.org/dyn/closer.cgi/xml/fop
eventually leads you to the old xml/fop directories, which are still
available (maybe to keep old links working), contain lots of old data,
fop-current files which certainly aren't current any more, and a subtitle
announcing 0.20.5 as the state of the art

You certainly want to correct that link, and maybe to consider updating the
old download pages ;-). It took me a whole minute to understand what was
wrong.


I've updated the page, which will go LIVE the next time someone
re-generates the site (and since this is release time, that's fairly
often!). Thanks for the report!


Keep up the good work on Fop !

Yannick Valot.


Thanks for the kind words, and for reporting this glitch!

--
Regards,

The Web Maestro
--
<[EMAIL PROTECTED]> - <http://homepage.mac.com/webmaestro/>
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

Re: [VOTE] Release of FOP 0.93

[The Web Maestro]

On 12/27/06, Chris Bowditch <[EMAIL PROTECTED]> wrote:

Simon Pepping wrote:
> I have prepared the release files for the FOP 0.93 release. They were
> created from the tag
> https://svn.apache.org/repos/asf/xmlgraphics/fop/tags/fop-0_93. You
> can find them at http://people.apache.org/~spepping/. They are signed
> with the same PGP key as this message. You can find this key in the
> KEYS file in the distribution. The MD5 checksums are:
>
> 42072ea508bd19c7d555cbea06d05b19  fop-0.93-bin-jdk1.3.tar.gz
> 96706ccd3142490f7399eea22d407780  fop-0.93-bin-jdk1.3.zip
> 8286783edcd500c52ae18923f616c8d6  fop-0.93-bin-jdk1.4.tar.gz
> e0a9e023a20e0ba1be0d09b2c4f67c38  fop-0.93-bin-jdk1.4.zip
> 60c8edbb93c10c27ace8e19dcb5c6f87  fop-0.93-bin-jdk1.5.tar.gz
> 9338ae7a3ac746fc3f685a0ab92c7b40  fop-0.93-bin-jdk1.5.zip
> ca41915df20f10a70f9602fd6016837d  fop-0.93-src.tar.gz
> bee7659eb7e0806f8e57b0d63449a339  fop-0.93-src.zip
>
> Herewith I start a vote on this release. The vote will end in 72
> hours, that is, on Saturday 30 December 2006 at noon UTC.

+1 from me. Thanks for your efforts in preparing the long overdue Release.

Chris


+1 from me on this. Thank you all for all of your hard work.

Please note, that I believe this should be a PMC VOTE [1], it hence
should occur on general@xmlgraphics.apache.org, and so I'm responding
to Chris's VOTE and adding [EMAIL PROTECTED] to the To: list.

[1]
http://www.apache.org/foundation/voting.html

--
Regards,

The Web Maestro
--
<[EMAIL PROTECTED]> - <http://homepage.mac.com/webmaestro/>
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

Re: Removing deprecated stuff in the High-level API

[The Web Maestro]

On 11/14/06, Jeremias Maerki <[EMAIL PROTECTED]> wrote:


On 14.11.2006 09:35:50 Vincent Hennebert wrote:
> Jeremias Maerki a écrit :
> > On 13.11.2006 22:24:27 J.Pietschmann wrote:
> >> Jeremias Maerki wrote:
> >>> If nobody objects I'm going to remove the deprecated elements in the
> >>> apps package later this week.


I think it'd be better to remove it before the release, since they
should not actually be useful for the release.

--
Regards,

The Web Maestro
--
<[EMAIL PROTECTED]> - <http://homepage.mac.com/webmaestro/>
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

Re: [VOTE:RESULT] Vincent Hennebert as new committer

[The Web Maestro]

Howdy folks,

Sorry for the delay... Vincent has my +1 as well. Welcome Vincent!

Web Maestro Clay

On 10/16/06, Vincent Hennebert <[EMAIL PROTECTED]> wrote:

Many thanks to all of you for your support. I'm glad to enter the XML
Graphics team. I think this is a team of really nice persons, it has
always been great to work with you as a contributor and it will be a
pleasure to work now as a committer.

At the GetTogether I felt what belonging to the Apache community really
means. To me this is one of the greatest aspects of open-source
development, and I'm proud to now be a member of such a community.

Thanks again, I'll do my best to deserve my new status!

Vincent


Jeremias Maerki a écrit :
> Ok, high time to wrap this up.
>
> We have:
> 10 +1
> 1 +0
> no other votes
> (6 of 8 PMC members have voted)
>
> Vincent is now an ASF committer with write access for FOP and XML
> Graphics Commons.
>
> Congratulations, Vincent, and welcome! I'll follow up with
> the administrative stuff in a second.
>
> On 11.10.2006 10:48:29 Jeremias Maerki wrote:
>> Simon and I were able too meet Vincent Hennebert in person in Amsterdam
>> last week. He has already made an impression with his excellent work for
>> the GSoC. He's a very nice and intelligent guy, eager to learn and to
>> work on FOP. Another guy who's not afraid to jump into the depths of the
>> layout engine.
>>
>> Since the GSoC he has found a job at Anyware
>> (http://www.anyware-tech.com), a French company which does a lot of
>> Cocoon stuff. There, he has the opportunity to work around 50% on FOP
>> sponsored by the same customer that enabled me to invest so much time
>> into FOP over the last two years.
>>
>> I'd like to propose Vincent as an XML Graphics committer (FOP working
>> set). I believe he will be a good addition to our work force.
>
>
>
> Jeremias Maerki
>
>
> -
> Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>

-------------
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
Regards,

The Web Maestro
--
<[EMAIL PROTECTED]> - <http://homepage.mac.com/webmaestro/>
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

Re: list moderation for fop-users

[The Web Maestro]

I suspect we need additional moderators. I've been having some issues  
which have been taking a lot of my time.


Clay

On Oct 7, 2006, at 4:38 AM, Jeremias Maerki wrote:

List moderator performance for fop-users was poor this week. I have  
not

been able to do anything from Wednesday to Friday and nobody else
handled the moderations requests. Is this just a glitch (holiday
absences etc.) or do we need additional moderators?

Jeremias Maerki

Re: Re: Configuration file problems

[The Web Maestro]

On 9/10/06, Jeremias Maerki <[EMAIL PROTECTED]> wrote:

On 10.09.2006 17:01:30 The Web Maestro wrote:
> On a related point, does it make sense that all configuration be
> handled in one place (e.g., fonts too)?

Can you explain further what you mean?


Sorry. For some reason I thought the FONT configuration was in a
different spot from normal FOP config. I re-read the FOP Config[1] &
the FONT configuration[2] sections again, and realized I was confusing
the PostScript & TrueType metrics file generation process with FOP's
configuration file.

Never mind!

[1] FOP Configuration:
http://xmlgraphics.apache.org/fop/0.92/configuration.html

[2] FOP Fonts Configuration:
http://xmlgraphics.apache.org/fop/0.92/fonts.html

--
Regards,

The Web Maestro
--
<[EMAIL PROTECTED]> - <http://homepage.mac.com/webmaestro/>
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

Re: Re: Configuration file problems

[The Web Maestro]

We could just identify the schema in the DOCTYPE (or DTD if we decide
to go that route--a schema is much more powerful, but isn't it more
overhead?). Then, we could alter the location at will. Instead of
embedding the file in FOP, it could be located either locally
(relative to FOP or the XML files), or it could be located on a remote
server.

As for validating, when someone creates a plug-in (or updates FOP to
handle some new, configurable feature), one portion of the PATCH would
update the fop-config.xsd file.

On a related point, does it make sense that all configuration be
handled in one place (e.g., fonts too)?

Clay

--
Regards,

The Web Maestro
--
<[EMAIL PROTECTED]> - <http://homepage.mac.com/webmaestro/>
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

Re: Beta release next week?

[The Web Maestro]

On Dec 14, 2005, at 11:29 AM, Andreas L Delmelle wrote:

On Dec 14, 2005, at 14:33, Jeremias Maerki wrote:

Given the number of bugs fixed and the feedback we got, I think it
should be safe to do another release tagged "beta". I don't care
too much about the exact version number.
I'll leave suggestions up to you. Release early, release often

WDYT?


+1. 0.90beta sounds fine to me.

Cheers,

Andreas


+1 for 0.90beta

IMO, we don't need to worry about 0.90beta1 or anything, because we can 
always bump to 0.91beta, etc. I assume 0.90 will be relatively 
unchanged from it's current state (e.g., won't include the FOray font 
stuff--which presumably would still come in pre-1.0?)


Regards,

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

Re: AFP Renderer for FOP

[The Web Maestro]

+1

On Nov 29, 2005, at 2:53 AM, Manuel Mall wrote:

I have been working lately on an AFP Renderer for FOP. As a starting
point I used http://afp-renderer.sourceforge.net. Some progress has
been made and some very basic rendering under fop trunk is working.

At the same time I have established contact with the original writers 
of

this software. As it turns out they are very keen to contribute their
code to the ASF. In actual fact all their code already has the Apache
2.0 license header.

Any way, I would like to formally ask on this list if there are any
objections (assuming all licensing issues are cleared by the PMC before
hand) to adding the AFP Renderer code to the fop trunk sandbox.

Regards

Manuel


Regards,

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