[Bug 44497] AFP Renderer: block reference orientation broken

http://issues.apache.org/bugzilla/show_bug.cgi?id=44497 Adrian Cumiskey <[EMAIL PROTECTED]> changed: What|Removed |Added CC||[EMAIL PROTECT

[Bug 44497] New: AFP Renderer: block reference orientation broken

http://issues.apache.org/bugzilla/show_bug.cgi?id=44497 Summary: AFP Renderer: block reference orientation broken Product: Fop Version: 1.0dev Platform: Other OS/Version: All Status: NEW Severity: enhancement Priori

[Bug 44497] AFP Renderer: block reference orientation broken

http://issues.apache.org/bugzilla/show_bug.cgi?id=44497 Jeremias Maerki <[EMAIL PROTECTED]> changed: What|Removed |Added Status|NEW |RESOLVED

Re: Supporting unusual encodings for Type 1 fonts

It turns out that implementing solution 1 isn't so easy in PDF. Actually, my naming was even wrong. It's not a CIDFont I wanted to use. I just wanted to use character codes larger than 255 as input to a CMap which spits out character names for Type 1 fonts (see illustration in PS Third Edition, pag

Re: Reverting changes in AFP Renderer

I'm not sure I follow you. Do you mean that you'd always maintain the transformation stack in the renderer? That's certainly something that needs to be done in a uniform way. For PDF/PS/Java2D you'd still always apply any transformation to the output formats. For PCL (and probably AFP) you wouldn't

Re: More ideas for configuration/extension?

I'm not sure I like this whole thing, yet. Of course, your suggestion is fine. But there's one thing that needs to be figured out: The configuration is applied to the FopFactory. Having the configuration on this level provides a multi-threading problem as multiple rendering runs might simultaneousl

Re: Compliance document

I can help with the release notes and changes. These are generated through XSLT and probably just need a bit of tweaking in the sitemap. The same probably applies to the compliance page. Maybe it was just a small sitemap problem. I'm still for keeping the versioned docs. Maybe you could upload what

Re: Compliance document

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 origin

Re: More ideas for configuration/extension?

For either my suggestion or Andreas' further proposal we would certainly need to do a little bit of refactoring, abstracting out all those member config variables in FopFactory into a base configuration object. This base configuration object would be a singleton and *unmodifiable* and would on

Re: More ideas for configuration/extension?

This scoping seems a little bit too clever for me ;-). I'm not sure how useful this use case would be. I think its useful enough to just have a document level configuration defined within the fo:declarations. Adrian. Andreas Delmelle wrote: Hi all Some time ago, Adrian posted an interesti

Re: Reverting changes in AFP Renderer

Reply below.. Jeremias Maerki wrote: I'm not sure I follow you. Do you mean that you'd always maintain the transformation stack in the renderer? That's certainly something that needs to be done in a uniform way. Yes, a base renderer/painter could maintain both the transformation stack and comm

Re: More ideas for configuration/extension?

On Feb 27, 2008, at 16:21, Adrian Cumiskey wrote: For either my suggestion or Andreas' further proposal we would certainly need to do a little bit of refactoring, abstracting out all those member config variables in FopFactory into a base configuration object. This base configuration obje

Re: future renderer design (was: Reverting changes in AFP Renderer)

On 27.02.2008 17:09:49 Adrian Cumiskey wrote: > Reply below.. > > Jeremias Maerki wrote: > > I'm not sure I follow you. Do you mean that you'd always maintain the > > transformation stack in the renderer? That's certainly something that > > needs to be done in a uniform way. > > Yes, a base rende