Quick survey: upcoming release of FOP 0.94

[Andreas L Delmelle]

Hi all


As some of you may already know, the fop-dev team is currently in the  
process of preparing a new release. With this post, we would like to  
gather some ideas on what the user community would like to see  
incorporated in FOP 0.94.

Note that the release will already contain some cool new features  
compared to 0.93, like support for border-collapse="collapse", auto-
detection and -registration of available custom fonts and  
improvements in handling internal destinations...

What we are currently looking for are not large improvements (like  
table-layout="auto", which we are well aware is still missing), but  
more the elimination of small annoyances, little things that could  
mean a great deal to you.

So, shoot away, and we'll see what we can do. No suggestion will be  
dismissed without consideration. Even if we do not implement the  
suggestion immediately, if it's interesting enough, we will  
definitely keep it in mind as a possible priority for the next release.

We would also like this to be an opportunity for users who are in a  
position where they are able to check out and build the 0.94 release  
branch that has been created (*), to see if we have overlooked  
anything in our testsuites. If any bugs or unexpected results turn up  
in your real-time scenarios, we would of course appreciate it very  
much if these are uncovered before the actual release.


As always, we value your input and feedback.


Thanks

Andreas

(*) http://svn.apache.org/repos/asf/xmlgraphics/fop/branches/fop-0_94/

---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@...
For additional commands, e-mail: fop-users-help@...

Are there perfomance enancements? I mean about the page sequence memory
consuption issue that prevent to use FOP in a production env for reports
bigger than 500 pages?

best regards
GM

>
> Hi all
>
>
> As some of you may already know, the fop-dev team is currently in the
> process of preparing a new release. With this post, we would like to
> gather some ideas on what the user community would like to see
> incorporated in FOP 0.94.
>
> Note that the release will already contain some cool new features
> compared to 0.93, like support for border-collapse="collapse", auto-
> detection and -registration of available custom fonts and
> improvements in handling internal destinations...
>
> What we are currently looking for are not large improvements (like
> table-layout="auto", which we are well aware is still missing), but
> more the elimination of small annoyances, little things that could
> mean a great deal to you.
>
> So, shoot away, and we'll see what we can do. No suggestion will be
> dismissed without consideration. Even if we do not implement the
> suggestion immediately, if it's interesting enough, we will
> definitely keep it in mind as a possible priority for the next release.
>
> We would also like this to be an opportunity for users who are in a
> position where they are able to check out and build the 0.94 release
> branch that has been created (*), to see if we have overlooked
> anything in our testsuites. If any bugs or unexpected results turn up
> in your real-time scenarios, we would of course appreciate it very
> much if these are uncovered before the actual release.
>
>
> As always, we value your input and feedback.
>
>
> Thanks
>
> Andreas
>
> (*) http://svn.apache.org/repos/asf/xmlgraphics/fop/branches/fop-0_94/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@...
> For additional commands, e-mail: fop-users-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@...
For additional commands, e-mail: fop-users-help@...

[Andreas L Delmelle]

On Jul 16, 2007, at 11:57, gmannelli@... wrote:

Hi

> Are there perfomance enancements?

Yes, in comparison to 0.93, there should be /some/ performance  
enhancements in terms of memory usage, especially in the FO tree, but...

> I mean about the page sequence memory
> consuption issue that prevent to use FOP in a production env for  
> reports
> bigger than 500 pages?

... this particular issue is still open. The root 'cause' for this  
limitation still exists in the 0.94 release, and has to do with FOP  
waiting for an endElement("page-sequence") event from the parser  
before entering the layout-phase.
The enhancements that were introduced could slightly increase this  
limit, but only marginally AFAICT.

As recently indicated in another thread, we welcome any suggestions  
in this area. The discussion is very much being kept alive. The more  
heads involved in it, the greater the chance those issues will ever  
get resolved.

Some ideas on improvement have been discussed on fop-dev earlier this  
year, but it was clear then, that it will by no means be a  
straightforward task, let alone a one-man-job.


Cheers

Andreas


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@...
For additional commands, e-mail: fop-users-help@...

[Kamal-6]

I guess float support is also out of the question, but that is top of my
wish lists. Working with tables and XSLT is painful. I don't know if it
is a big or small change, but as I pointed out in previous posts, I
think having no integer support for keep-together, keep-with-next,
keep-with-previous is a major flaw as it makes it next to useless to
me[1]. Also, it would be nice to see the table continuation labels
extension return to FOP.

On the topic of extensions, I found the way borders work at the region
level counter intuitive when combined with columns (ie, if you specify a
border, it puts it around each column, not the region). It would be nice
to have as an extension to FOP that made this work sensibly, eg, a set
of region border attributes. Hope that makes sense.

Auto detection and auto registration of custom fonts sounds good. Can we
have more info?

Kamal.

[1] http://marc.info/?l=fop-user&m=118171831815966&w=2

---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@...
For additional commands, e-mail: fop-users-help@...

[HLeonardi]

Hugues Leonardi wrote:

So, shoot away, and we'll see what we can do. No suggestion will be  
dismissed without consideration. Even if we do not implement the  
suggestion immediately, if it's interesting enough, we will  
definitely keep it in mind as a possible priority for the next release.

About footnotes :
There was a little patch in the patch queue that adds footnotes from table cell or list item. This patch do the job well. I know that is a great work to implement the whole of this functionnality but if this patch could be added, it would be nice.


We would also like this to be an opportunity for users who are in a  
position where they are able to check out and build the 0.94 release  
branch that has been created (*), to see if we have overlooked  
anything in our testsuites. If any bugs or unexpected results turn up  
in your real-time scenarios, we would of course appreciate it very  
much if these are uncovered before the actual release.

I will download and test the 0.94. But, I regulary download and build fop-trunk. It works well. Here is a little feedback about pdf output:
- external-links between documents  : OK with acrobat reader only
- exact positioning of bookmarks links : 0K
- improvements about tables : not tested yet
- font autodetection : I have tested this feature but the results were wrongs. When I have a little time, I will take a look at the doc and I test again.
other improvements : not tested

Best regards

Hugues Leonardi

 

[Thomas Zastrow-4]

Andreas L Delmelle schrieb:
>
>
> We would also like this to be an opportunity for users who are in a
> position where they are able to check out and build the 0.94 release
> branch that has been created (*), to see if we have overlooked
> anything in our testsuites. If any bugs or unexpected results turn up
> in your real-time scenarios, we would of course appreciate it very
> much if these are uncovered before the actual release.
>
Hello,

I tried my "st scripts" (http://www.thomas-zastrow.de/st/) with the 0.94
release branch, works perfect!

Thank you!!!

Tom



--
----------------------------
http://www.thomas-zastrow.de

German Forum - DTP under Linux:

http://www.opendtp.de
----------------------------


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@...
For additional commands, e-mail: fop-users-help@...

[Andreas L Delmelle]

On Jul 16, 2007, at 15:33, Kamal wrote:

Hi Kamal

> I guess float support is also out of the question, but that is top  
> of my wish lists.

Unfortunately, yes. If I judge the status of the Temp_Floats code-
branch correctly, it is not yet ready to be merged back into the  
trunk anytime soon... That said, the branch is there. The only thing  
lacking is heads and hands to work on it.

> Working with tables and XSLT is painful. I don't know if it is a  
> big or small change, but as I pointed out in previous posts, I  
> think having no integer support for keep-together, keep-with-next,  
> keep-with-previous is a major flaw as it makes it next to useless  
> to me[1].

This would be a rather big project, IIC. Not necessarily difficult,  
but a lot of work. AFAICT, there have been no parties yet that have  
started to gather ideas. We'll see if we can at least start a Wiki  
about this, where you could follow the status and comment in on  
possible implementations.

> Also, it would be nice to see the table continuation labels  
> extension return to FOP.

I noticed indeed this recently popped up as a reason for some to  
still prefer using 0.20.5 over 0.93. This will have to addressed  
sooner rather than later.

> On the topic of extensions, I found the way borders work at the  
> region level counter intuitive when combined with columns (ie, if  
> you specify a border, it puts it around each column, not the  
> region). It would be nice to have as an extension to FOP that made  
> this work sensibly, eg, a set of region border attributes. Hope  
> that makes sense.

It does. On the other hand, I'm just now wondering whether your  
problem here cannot be solved by using fo:block-containers to hold  
the borders... Have you tried this?

> Auto detection and auto registration of custom fonts sounds good.  
> Can we have more info?

Well, it's not perfect, yet, but the basic idea is that users should  
not need to worry about registering custom fonts. If the Arial  
TrueType font is present on the system where FOP runs, then the user  
should now be able to use that font in his FO documents without  
taking any additional steps (like generating metrics and registering  
triplets in the configuration file).


Cheers

Andreas


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@...
For additional commands, e-mail: fop-users-help@...

[Adrian Cumiskey]

Hi Hugues,

HLeonardi wrote:
>> - font autodetection : I have tested this feature but the results were
>> wrongs. When I have a little time, I will take a look at the doc and I
>> test again.

It would be great if you could provide me some more information about
this please.  I am pretty sure that the font autodetection will require
*some* tweaking and refinement - so user testing and feedback is really
helpful.  What system do you use to run FOP?  How were the results wrong?

Cheers,

Adrian.

---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@...
For additional commands, e-mail: fop-users-help@...

[Kamal-6]

>> I guess float support is also out of the question, but that is top  
>> of my wish lists.
>
>
> Unfortunately, yes. If I judge the status of the Temp_Floats code-
> branch correctly, it is not yet ready to be merged back into the  
> trunk anytime soon... That said, the branch is there. The only thing  
> lacking is heads and hands to work on it.

Pity

>
>> Working with tables and XSLT is painful. I don't know if it is a  big
>> or small change, but as I pointed out in previous posts, I  think
>> having no integer support for keep-together, keep-with-next,  
>> keep-with-previous is a major flaw as it makes it next to useless  to
>> me[1].
>
>
> This would be a rather big project, IIC. Not necessarily difficult,  
> but a lot of work. AFAICT, there have been no parties yet that have  
> started to gather ideas. We'll see if we can at least start a Wiki  
> about this, where you could follow the status and comment in on  
> possible implementations.
>
>> Also, it would be nice to see the table continuation labels  
>> extension return to FOP.
>
>
> I noticed indeed this recently popped up as a reason for some to  
> still prefer using 0.20.5 over 0.93. This will have to addressed  
> sooner rather than later.

That would be nice.

>
>> On the topic of extensions, I found the way borders work at the  
>> region level counter intuitive when combined with columns (ie, if  
>> you specify a border, it puts it around each column, not the  
>> region). It would be nice to have as an extension to FOP that made  
>> this work sensibly, eg, a set of region border attributes. Hope  that
>> makes sense.
>
>
> It does. On the other hand, I'm just now wondering whether your  
> problem here cannot be solved by using fo:block-containers to hold  
> the borders... Have you tried this?

I will have a go. I assume you mean put the content that will be
columnised into a block container and put the border around the block
container?

>
>> Auto detection and auto registration of custom fonts sounds good.  
>> Can we have more info?
>
>
> Well, it's not perfect, yet, but the basic idea is that users should  
> not need to worry about registering custom fonts. If the Arial  
> TrueType font is present on the system where FOP runs, then the user  
> should now be able to use that font in his FO documents without  
> taking any additional steps (like generating metrics and registering  
> triplets in the configuration file).

How does this work in a Unix environment?



---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@...
For additional commands, e-mail: fop-users-help@...

[Luis Ferro]

In FOP 0.93, page references are kept in ways that preserve the whole original pages objects. No problem with that except that this process is TOO memory intensive and exausts the heap memory if you have too many pages, segments and references.

What i would like to see in a future FOP release would be a "minimalist" object that retains only the "references" after the page is created, allowing the "unload" of the whole page. When the "reference" is requested after it, the current page sequence would be queried, and if not found, the "minimalist" collection would be searched. If the reference isn't the the collection either, it would give a "reference not found" error as it gives today.

That mechanism would allow for huge documents, with huge lists of references, to be created without compromising the heap memory, because only the current sequence would be kept in memory.

Cheers,
LF


gmannelli@... escreveu:

Are there perfomance enancements? I mean about the page sequence memory
consuption issue that prevent to use FOP in a production env for reports
bigger than 500 pages?

best regards
GM

  

Hi all


As some of you may already know, the fop-dev team is currently in the
process of preparing a new release. With this post, we would like to
gather some ideas on what the user community would like to see
incorporated in FOP 0.94.

Note that the release will already contain some cool new features
compared to 0.93, like support for border-collapse="collapse", auto-
detection and -registration of available custom fonts and
improvements in handling internal destinations...

What we are currently looking for are not large improvements (like
table-layout="auto", which we are well aware is still missing), but
more the elimination of small annoyances, little things that could
mean a great deal to you.

So, shoot away, and we'll see what we can do. No suggestion will be
dismissed without consideration. Even if we do not implement the
suggestion immediately, if it's interesting enough, we will
definitely keep it in mind as a possible priority for the next release.

We would also like this to be an opportunity for users who are in a
position where they are able to check out and build the 0.94 release
branch that has been created (*), to see if we have overlooked
anything in our testsuites. If any bugs or unexpected results turn up
in your real-time scenarios, we would of course appreciate it very
much if these are uncovered before the actual release.


As always, we value your input and feedback.


Thanks

Andreas

(*) http://svn.apache.org/repos/asf/xmlgraphics/fop/branches/fop-0_94/

---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@...
For additional commands, e-mail: fop-users-help@...


    

[Vincent HENNEUSE]

Hi,

I wish that one day, fop will support the element fo:change-bar described in the  xsl spec 1.1.

I know that this is impossible for the next release, but in the future it will be great that fop integrates this object.

Thanks.

[HLeonardi]

Hugues wrote:

Hi Adrian,

OK, I test again and I open new thread.

Hugues Leonardi

Hi Hugues,

HLeonardi wrote:
>> - font autodetection : I have tested this feature but the results were
>> wrongs. When I have a little time, I will take a look at the doc and I
>> test again.

It would be great if you could provide me some more information about
this please.  I am pretty sure that the font autodetection will require
*some* tweaking and refinement - so user testing and feedback is really
helpful.  What system do you use to run FOP?  How were the results wrong?

Cheers,

Adrian.

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

[Jeremias Maerki-2]

On 17.07.2007 14:39:29 Kamal wrote:
<snip/>

> >> Auto detection and auto registration of custom fonts sounds good.  
> >> Can we have more info?
> >
> >
> > Well, it's not perfect, yet, but the basic idea is that users should  
> > not need to worry about registering custom fonts. If the Arial  
> > TrueType font is present on the system where FOP runs, then the user  
> > should now be able to use that font in his FO documents without  
> > taking any additional steps (like generating metrics and registering  
> > triplets in the configuration file).
>
> How does this work in a Unix environment?

Some known font locations are preconfigured in FOP. FOP goes looking for
fonts in those directories. Additional locations can easily be
configured in the user configuration.

See http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/autodetect/UnixFontDirFinder.java?view=markup

Jeremias Maerki


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@...
For additional commands, e-mail: fop-users-help@...

[Adrian Cumiskey]

Hi Kamal,

FYI, the Unix autodetect feature looks in the following locations for
fonts it can use :-

java user.home + "/.fonts",
"/usr/local/fonts",
"/usr/share/fonts",
"/usr/X11R6/lib/X11/fonts"

As Jeremias says, you can configure FOP to look in a particular
<directory/> (see http://xmlgraphics.apache.org/fop/trunk/fonts.html).

Adrian.

Jeremias Maerki wrote:

> On 17.07.2007 14:39:29 Kamal wrote:
> <snip/>
>>>> Auto detection and auto registration of custom fonts sounds good.  
>>>> Can we have more info?
>>>
>>> Well, it's not perfect, yet, but the basic idea is that users should  
>>> not need to worry about registering custom fonts. If the Arial  
>>> TrueType font is present on the system where FOP runs, then the user  
>>> should now be able to use that font in his FO documents without  
>>> taking any additional steps (like generating metrics and registering  
>>> triplets in the configuration file).
>> How does this work in a Unix environment?
>
> Some known font locations are preconfigured in FOP. FOP goes looking for
> fonts in those directories. Additional locations can easily be
> configured in the user configuration.
>
> See http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/autodetect/UnixFontDirFinder.java?view=markup
>
> Jeremias Maerki
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@...
> For additional commands, e-mail: fop-users-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@...
For additional commands, e-mail: fop-users-help@...

[Loran Kary]

How does this work in a Macintosh OS X environment?

On Jul 18, 2007, at 5:53 AM, Jeremias Maerki wrote:

>
> On 17.07.2007 14:39:29 Kamal wrote:
> <snip/>
>>>> Auto detection and auto registration of custom fonts sounds good.
>>>> Can we have more info?
>>>
>>>
>>> Well, it's not perfect, yet, but the basic idea is that users should
>>> not need to worry about registering custom fonts. If the Arial
>>> TrueType font is present on the system where FOP runs, then the user
>>> should now be able to use that font in his FO documents without
>>> taking any additional steps (like generating metrics and registering
>>> triplets in the configuration file).
>>
>> How does this work in a Unix environment?
>
> Some known font locations are preconfigured in FOP. FOP goes  
> looking for
> fonts in those directories. Additional locations can easily be
> configured in the user configuration.
>
> See http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/src/java/org/ 
> apache/fop/fonts/autodetect/UnixFontDirFinder.java?view=markup
>
> Jeremias Maerki
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@...
> For additional commands, e-mail: fop-users-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@...
For additional commands, e-mail: fop-users-help@...

[Andreas L Delmelle]

On Jul 19, 2007, at 19:38, Loran Kary wrote:

> How does this work in a Macintosh OS X environment?

Quite good, apart from the fact that certain fonts apparently are  
unsuitable to be used by FOP. They are all nicely detected, but you  
get errors about missing Unicode CMAPs or invalid ascender/descender  
pairs... Haven't really looked closer into the causes of those, but  
the auto-detection routine works fine in any case.

here you can find the default locations that are searched for fonts:
http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/src/java/org/ 
apache/fop/fonts/autodetect/MacFontDirFinder.java?view=markup


Cheers

Andreas


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@...
For additional commands, e-mail: fop-users-help@...

[Loran Kary]

The default locations look good.  But I know there are some  
differences between Windows TrueType fonts and Macintosh TrueType  
fonts.  They use different tables for certain things.  I would be  
nice if FOP could be made to work with Macintosh TrueType fonts.

-- Loran Kary

On Jul 19, 2007, at 10:49 AM, Andreas L Delmelle wrote:

> On Jul 19, 2007, at 19:38, Loran Kary wrote:
>
>> How does this work in a Macintosh OS X environment?
>
> Quite good, apart from the fact that certain fonts apparently are  
> unsuitable to be used by FOP. They are all nicely detected, but you  
> get errors about missing Unicode CMAPs or invalid ascender/
> descender pairs... Haven't really looked closer into the causes of  
> those, but the auto-detection routine works fine in any case.
>
> here you can find the default locations that are searched for fonts:
> http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/src/java/org/ 
> apache/fop/fonts/autodetect/MacFontDirFinder.java?view=markup
>
>
> Cheers
>
> Andreas
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@...
> For additional commands, e-mail: fop-users-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@...
For additional commands, e-mail: fop-users-help@...

[Roland Neilands]

I suggest PCL6 support.

A late response I know, but this just came up recently & I can't work
around it.
PCL 5 support is being dropped from some new printers it seems:
http://h20000.www2.hp.com/bc/docs/support/SupportManual/c00878487/c00878487.pdf

This has happened a couple of times recently, & the printers don't have
usable postscript support, and bitmapping the fonts in 0.93 sadly didn't
resolve the issue (better, but still not adequate).
It remains for me to say "buy another printer". I wonder how long that
answer will fly?

Regards,
Roland


Andreas L Delmelle wrote:

>
> Hi all
>
>
> As some of you may already know, the fop-dev team is currently in the
> process of preparing a new release. With this post, we would like to
> gather some ideas on what the user community would like to see
> incorporated in FOP 0.94.
>
> Note that the release will already contain some cool new features
> compared to 0.93, like support for border-collapse="collapse",
> auto-detection and -registration of available custom fonts and
> improvements in handling internal destinations...
>
> What we are currently looking for are not large improvements (like
> table-layout="auto", which we are well aware is still missing), but
> more the elimination of small annoyances, little things that could
> mean a great deal to you.
>
> So, shoot away, and we'll see what we can do. No suggestion will be
> dismissed without consideration. Even if we do not implement the
> suggestion immediately, if it's interesting enough, we will definitely
> keep it in mind as a possible priority for the next release.
>
> We would also like this to be an opportunity for users who are in a
> position where they are able to check out and build the 0.94 release
> branch that has been created (*), to see if we have overlooked
> anything in our testsuites. If any bugs or unexpected results turn up
> in your real-time scenarios, we would of course appreciate it very
> much if these are uncovered before the actual release.
>
>
> As always, we value your input and feedback.
>
>
> Thanks
>
> Andreas
>
> (*) http://svn.apache.org/repos/asf/xmlgraphics/fop/branches/fop-0_94/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@...
> For additional commands, e-mail: fop-users-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@...
For additional commands, e-mail: fop-users-help@...

[Jeremias Maerki-2]

Quite a bit of work, what you suggest here. PCL 6 (aka PCL XL) is
a completely different printer language compared to PCL 5. We'd have to
develop a completely new renderer. Do you have a budget for this? ;-)

What does that mean: "better, but still not adequate"? Does it print
correctly on those printers or not? What's the problem?

On 31.07.2007 08:48:08 Roland Neilands wrote:

> I suggest PCL6 support.
>
> A late response I know, but this just came up recently & I can't work
> around it.
> PCL 5 support is being dropped from some new printers it seems:
> http://h20000.www2.hp.com/bc/docs/support/SupportManual/c00878487/c00878487.pdf
>
> This has happened a couple of times recently, & the printers don't have
> usable postscript support, and bitmapping the fonts in 0.93 sadly didn't
> resolve the issue (better, but still not adequate).
> It remains for me to say "buy another printer". I wonder how long that
> answer will fly?
>
> Regards,
> Roland
>
>
> Andreas L Delmelle wrote:
> >
> > Hi all
> >
> >
> > As some of you may already know, the fop-dev team is currently in the
> > process of preparing a new release. With this post, we would like to
> > gather some ideas on what the user community would like to see
> > incorporated in FOP 0.94.
> >
> > Note that the release will already contain some cool new features
> > compared to 0.93, like support for border-collapse="collapse",
> > auto-detection and -registration of available custom fonts and
> > improvements in handling internal destinations...
> >
> > What we are currently looking for are not large improvements (like
> > table-layout="auto", which we are well aware is still missing), but
> > more the elimination of small annoyances, little things that could
> > mean a great deal to you.
> >
> > So, shoot away, and we'll see what we can do. No suggestion will be
> > dismissed without consideration. Even if we do not implement the
> > suggestion immediately, if it's interesting enough, we will definitely
> > keep it in mind as a possible priority for the next release.
> >
> > We would also like this to be an opportunity for users who are in a
> > position where they are able to check out and build the 0.94 release
> > branch that has been created (*), to see if we have overlooked
> > anything in our testsuites. If any bugs or unexpected results turn up
> > in your real-time scenarios, we would of course appreciate it very
> > much if these are uncovered before the actual release.
> >
> >
> > As always, we value your input and feedback.
> >
> >
> > Thanks
> >
> > Andreas
> >
> > (*) http://svn.apache.org/repos/asf/xmlgraphics/fop/branches/fop-0_94/
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: fop-users-unsubscribe@...
> > For additional commands, e-mail: fop-users-help@...
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@...
> For additional commands, e-mail: fop-users-help@...

---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@...
For additional commands, e-mail: fop-users-help@...

[Roland Neilands]

To redevelop something that worked before to look exactly the same
because HP dropped their own format? No, no budget yet & no sense of
futility either. :)

I've set this to do the font bitmapping, not sure that it's working as
the font sizes aren't right, but they don't overlap so much:
conf/fop.xconf:
...
    <renderer mime="application/vnd.hp-PCL">
      <!-- render all text as bitmaps using Java 2D -->
      <text-rendering>bitmap</text-rendering>
    </renderer>

It looks the same as the PDF version on other printers though, so I
can't reproduce it personally ...
I'll try to get an example.

Regards,
Roland

Jeremias Maerki wrote:

> Quite a bit of work, what you suggest here. PCL 6 (aka PCL XL) is
> a completely different printer language compared to PCL 5. We'd have to
> develop a completely new renderer. Do you have a budget for this? ;-)
>
> What does that mean: "better, but still not adequate"? Does it print
> correctly on those printers or not? What's the problem?
>
> On 31.07.2007 08:48:08 Roland Neilands wrote:
>  
>> I suggest PCL6 support.
>>
>> A late response I know, but this just came up recently & I can't work
>> around it.
>> PCL 5 support is being dropped from some new printers it seems:
>> http://h20000.www2.hp.com/bc/docs/support/SupportManual/c00878487/c00878487.pdf
>>
>> This has happened a couple of times recently, & the printers don't have
>> usable postscript support, and bitmapping the fonts in 0.93 sadly didn't
>> resolve the issue (better, but still not adequate).
>> It remains for me to say "buy another printer". I wonder how long that
>> answer will fly?
>>
>> Regards,
>> Roland
>>
>>
>> Andreas L Delmelle wrote:
>>    
>>> Hi all
>>>
>>>
>>> As some of you may already know, the fop-dev team is currently in the
>>> process of preparing a new release. With this post, we would like to
>>> gather some ideas on what the user community would like to see
>>> incorporated in FOP 0.94.
>>>
>>> Note that the release will already contain some cool new features
>>> compared to 0.93, like support for border-collapse="collapse",
>>> auto-detection and -registration of available custom fonts and
>>> improvements in handling internal destinations...
>>>
>>> What we are currently looking for are not large improvements (like
>>> table-layout="auto", which we are well aware is still missing), but
>>> more the elimination of small annoyances, little things that could
>>> mean a great deal to you.
>>>
>>> So, shoot away, and we'll see what we can do. No suggestion will be
>>> dismissed without consideration. Even if we do not implement the
>>> suggestion immediately, if it's interesting enough, we will definitely
>>> keep it in mind as a possible priority for the next release.
>>>
>>> We would also like this to be an opportunity for users who are in a
>>> position where they are able to check out and build the 0.94 release
>>> branch that has been created (*), to see if we have overlooked
>>> anything in our testsuites. If any bugs or unexpected results turn up
>>> in your real-time scenarios, we would of course appreciate it very
>>> much if these are uncovered before the actual release.
>>>
>>>
>>> As always, we value your input and feedback.
>>>
>>>
>>> Thanks
>>>
>>> Andreas
>>>
>>> (*) http://svn.apache.org/repos/asf/xmlgraphics/fop/branches/fop-0_94/
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: fop-users-unsubscribe@...
>>> For additional commands, e-mail: fop-users-help@...
>>>
>>>      
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: fop-users-unsubscribe@...
>> For additional commands, e-mail: fop-users-help@...
>>    
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@...
> For additional commands, e-mail: fop-users-help@...
>
>  

---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@...
For additional commands, e-mail: fop-users-help@...