You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by "Townsend, Pete" <pe...@landg.com> on 2007/03/12 17:14:12 UTC

AFP Renderer Barcode Support

Dear fop-dev,

I'm the author of the AFPRenderer at http://afp-renderer.sourceforge.net/
which was ported across to fop-0.93 by Manuel Mall. It's great to see if
emerge in the 0.93 release thanks for everyone's effort in getting this out
and for including the AFP renderer.

I have been working on an enhancement to support the AFP BCOCA
(BarCodeObjectContentArchitecture) and wanted to gauge your opinion on
whether I can get this patch applied to the development, it's a few weeks
off completion at the moment. I'm aware that Barcode4J provide very good
barcode support, however the project I'm working on involves very high
volume outsourced printing and hence even the overhead of a 6kb image means
that this would not be feasible. For background, AFP is a very efficient
print stream format.  Static resources (fonts, overlays, etc.) are only
transmitted once, with the result that a full page of text can be typically
about 1-2K kb. The advantage of using BCOCA is that the barcode is
transmitted as very small dataset.

Many thanks, Pete Townsend

  


This e-mail (and any attachments) may contain privileged and/or confidential information. If you are not the intended recipient please do not disclose, copy, distribute, disseminate or take any action in reliance on it. If you have received this message in error please reply and tell us and then delete it. Should you wish to communicate with us by e-mail we cannot guarantee the security of any data outside our own computer systems. For the protection of Legal & General's systems and staff, incoming emails will be automatically scanned.

Any information contained in this message may be subject to applicable terms and conditions and must not be construed as giving investment advice within or outside the United Kingdom.

The following companies are subsidiary companies of the Legal & General Group Plc which are authorised and regulated by the Financial Services Authority for advising and arranging the products shown: Legal & General Partnership Services Limited (insurance and mortgages), Legal & General Insurance Limited (insurance), Legal & General Assurance Society Limited 
(life assurance, pensions and investments), Legal & General Unit Trust Managers Limited and Legal & General Portfolio Management Services Limited (investments).

They are registered in England under numbers shown.
The registered office is Temple Court, 11 Queen Victoria Street, London EC4N 4TP.

Legal & General Partnership Services Limited: 5045000 Legal & General Assurance Society Limited: 166055 Legal & General (Unit Trust Managers) Limited: 1009418 Legal & General (Portfolio Management Services) Limited: 2457525 Legal & General Insurance Limited: 423930

They are registered with the Financial Services Authority under numbers shown. You can check this at www.fsa.gov.uk/register

Legal & General Partnership Services Limited: 300792 Legal & General Assurance Society Limited: 117659 Legal & General (Unit Trust Managers) Limited: 119273 Legal & General (Portfolio Management Services) Limited: 146786 Legal & General Insurance Limited: 202050


Re: AFP Renderer Barcode Support

Posted by Andreas L Delmelle <a_...@pandora.be>.
On Mar 12, 2007, at 17:14, Townsend, Pete wrote:

Hi,

> I'm the author of the AFPRenderer at http://afp- 
> renderer.sourceforge.net/
> which was ported across to fop-0.93 by Manuel Mall. It's great to  
> see if
> emerge in the 0.93 release thanks for everyone's effort in getting  
> this out
> and for including the AFP renderer.

Well, a Big Thanks to /you/ for allowing FOP to incorporate it in the  
first place! :)

> I have been working on an enhancement to support the AFP BCOCA
> (BarCodeObjectContentArchitecture) and wanted to gauge your opinion on
> whether I can get this patch applied to the development, it's a few  
> weeks
> off completion at the moment. I'm aware that Barcode4J provide very  
> good
> barcode support, however the project I'm working on involves very high
> volume outsourced printing and hence even the overhead of a 6kb  
> image means
> that this would not be feasible. For background, AFP is a very  
> efficient
> print stream format.  Static resources (fonts, overlays, etc.) are  
> only
> transmitted once, with the result that a full page of text can be  
> typically
> about 1-2K kb. The advantage of using BCOCA is that the barcode is
> transmitted as very small dataset.

This definitely seems like a worthwhile addition to me. I don't see  
how we could refuse the offer, even with Jeremias being the author of  
Barcode4J... It does not seem like a collision of interests.

I have only one question (just out of curiosity):
Are you also implementing a FOP extension element (especially for use  
with the AFPRenderer), or on what basis are your barcodes rendered?


Cheers,

Andreas

Re: Is that correct jar in SVN: xmlgraphics-commons-1.2svn.jar?

Posted by Andreas L Delmelle <a_...@pandora.be>.
On Mar 13, 2007, at 12:12, Andrejus Chaliapinas wrote:

Hi Andrejus,

> Just wonder if that "svn" suffix in jar name for
> xmlgraphics-commons-1.2svn.jar is correct. I could see it under  
> trunk lib
> directory.
>
> I think that previously we had just xmlgraphics-commons-1.1.jar

That's indeed the correct JAR, which was replaced in the repository  
by Jeremias, after he added new functionality to XML Graphics Commons  
and Gump started complaining.
Commons 1.2 is not yet released by itself, hence the suffix 'svn'.

Cheers,

Andreas


Re: Is that correct jar in SVN: xmlgraphics-commons-1.2svn.jar?

Posted by Adrian Cumiskey <ad...@gmail.com>.
I believe this might probably be an Apache naming convention... but it 
may not be such a grand reason... :-)

Andrejus Chaliapinas wrote:
> Hi,
> 
> Just wonder if that "svn" suffix in jar name for
> xmlgraphics-commons-1.2svn.jar is correct. I could see it under trunk lib
> directory. 
> 
> I think that previously we had just xmlgraphics-commons-1.1.jar
> 
> Andrejus
> 
> 


Is that correct jar in SVN: xmlgraphics-commons-1.2svn.jar?

Posted by Andrejus Chaliapinas <a....@infosana.com>.
Hi,

Just wonder if that "svn" suffix in jar name for
xmlgraphics-commons-1.2svn.jar is correct. I could see it under trunk lib
directory. 

I think that previously we had just xmlgraphics-commons-1.1.jar

Andrejus


Re: AFP Renderer Barcode Support

Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
Hi Pete

Good to see you back here again. I wondered about the AFP Barcode stuff
myself. It makes perfect sense to make use of BCOCA. I'm aware of its
presence but haven't looked into the details. If a plugin for Barcode4J
could be created that automatically generates the optimal representation,
I don't know but it would obviously be optimal. But I don't think it
would be bad if you did it in a proprietary way (as an AFP extension
element) for the AFP renderer.

Looking forward to seeing a patch!

On 12.03.2007 17:14:12 Townsend, Pete wrote:
> Dear fop-dev,
> 
> I'm the author of the AFPRenderer at http://afp-renderer.sourceforge.net/
> which was ported across to fop-0.93 by Manuel Mall. It's great to see if
> emerge in the 0.93 release thanks for everyone's effort in getting this out
> and for including the AFP renderer.
> 
> I have been working on an enhancement to support the AFP BCOCA
> (BarCodeObjectContentArchitecture) and wanted to gauge your opinion on
> whether I can get this patch applied to the development, it's a few weeks
> off completion at the moment. I'm aware that Barcode4J provide very good
> barcode support, however the project I'm working on involves very high
> volume outsourced printing and hence even the overhead of a 6kb image means
> that this would not be feasible. For background, AFP is a very efficient
> print stream format.  Static resources (fonts, overlays, etc.) are only
> transmitted once, with the result that a full page of text can be typically
> about 1-2K kb. The advantage of using BCOCA is that the barcode is
> transmitted as very small dataset.
> 
> Many thanks, Pete Townsend
> 
>   
<snip/>


Jeremias Maerki