----------------------------------------
> Date: Fri, 8 Jan 2010 11:06:43 +0100
> From:
> To: [email protected]
> Subject: Re: [iText-questions] Embedding subset of fonts
>
> Thanks for the lively discussion.
> I totally agree to Leonard's comment, I have to, better must, archive the
> final (absolutly the same file as the print provider got used) version of
> the single PDF, so there is no way to produce or dispart on modules like
> text and font.
>
> On the other side, the generating, mean validate the jasperreport fields
> and rendering the PDF happens for a data collection of more then 10-15.000
> records, should work as fast as possible. So the process loads the data
> from the DB, validate, render the PDF, creates the file (huge PDF) and
> sends to the print provider. This should work as fast as possible.
>
> Later, after finishing all letter production, the splitting process
> starting and have enough time to finish the job (archive the single
> documents into the DB, referencing each record loaded before). The
> end-user can load the single document(invoice, letter, etc.) in a fast way
> and be sure seeing the final version. This is fine and is running stable
> since few years.
>
> Times have changed - we are using exotic fonts, given as ttf, so we need
> to embed them -- requirement from the print provider. Further we won't
> explode the DB.
>
> Don't misunderstood me pls, won't teach you or repeat myself, but the
> system and the process is given, running stable. So we are searching for
> the "best complement solution", without extremly burden the budget.
>
Your original concern suggested it wouldn't be stable as you had
to store more stuff along with your data- and I guess this is
a recurring problem.It may or may
not be the case that buying more terbytes is your cheapest stable solution.
I certainly understand that problems in trying to write code to fix
poorly posed problems. People think they are using a flexible
robust standard but it isn't flexible when used as an artificial
constraint that just requires more resources to support.
That's fine for a private company you can do whatever you want but often
the US agencies solicit input on various topics and PDF's have shown up
everywhere creating various limitations depending on how they are used.
Many times I will contribute input based on awareness of issues like this.
If you are worried about size and impact on performance, this sounds
like a case where someone's understanding of a law is reducing performance
while providing no additional value to anyone.
What you are saying is that they won't allow compression or zip files
inside the DB etc- if you preserve the algorithm ( in DB for that matter LOL)
which is itext and your code, all the input data ( which even pdf people may
put into db
from time to time ) then you are simply compressing your pdf with
a transform that allows things like indexing etc ( the text is easier to
index than pixels and you rarely want to search for fonts which have
no relationship to information that can't be better represented by something
indicating "this is a header" ). Depending on how the DB or repository works,
you may not even be able to point to a "PDF FILE" anywhere on the disk- with
embedded compression or encryption for example and you rely on the OS file
system
to reconstruct your "original" file from sectors in any case. Whatever law you
are
talking about is not enforceable except by creating dumber criteria unless it
just wants some assurance you can pull out an exact copy of whatever you sent
out
originally. Certainly buggy code, say your code around itext that inadvertently
uses random numbers or
has threading issues, will make it less reliable than a commercial product
like winzip decompress but I wouldn't use that for production anyway ( you
should have
signatures for the page images you generate for your own sanity checks for
example).
I would just mention that decomposition into "things" that represent
a signal is a great way to compress data. This not only makes it
smaller, but usually makes it more versatile as often a Fourier
spectrum of sound creates coefficients of more interest than a time
series ( you could at least ask " is this a single tone?" or something
reasonably easily from
that ). PDF of course is usually generated by decompressing your
input coefficients - which generally happen to be things like ASCII text
and some images and formatting rules- creating a "decompressed" file that
happens to be human readable but is not always invertible back to the
input information.
I'll admit it took me a while to trust winzip too but I never would
have made a law stopping people from using it. LOL.
And, agaiin, if you really want ( and should intenally anyway to validate your
own
work ) you can hash images to generate signatures and make sure they match
the "original" etc. In short, if you have enough internal controls to make sure
anything works, it shouldn't be a great leap of faith to store input data
rather than
something resembling a pdf file explicitly- you can just move itext back a
little in the work
flow, if it works anywhere it will work fine there.
> Zoltan
>
_________________________________________________________________
Hotmail: Powerful Free email with security by Microsoft.
http://clk.atdmt.com/GBL/go/196390710/direct/01/
------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
iText-questions mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/itext-questions
Buy the iText book: http://www.1t3xt.com/docs/book.php
Check the site with examples before you ask questions:
http://www.1t3xt.info/examples/
You can also search the keywords list: http://1t3xt.info/tutorials/keywords/
