Just to interject a potential complication (and potential solution)
with this scenario. When a pdf file is emailed, it becomes a static
document (the data will always be the same, today, tomorrow, next
year). When it is a link, it remains dynamic. In some instances you
want the data to remain dynamic and in some instances you want it to be
static.
To maintain a static document and use the approach that you are
suggesting, the data that exists when the document would have been
created needs to be stored somewhere. You likely will need to create a
data document and store on the server so that the report can then be
generated in the various languages on the fly. XML is likely a better
storage mechanism for most reports than is a RDBMS. If you're using
XML, an XML database is likely to be more beneficial than simple xml
file storage. And, there is already a basic implementation of an XML
database in Jira (Xindice).
FWIW,
Chris
--- Krzysztof Podejma <[EMAIL PROTECTED]> wrote:
> Oleg,
> I'm thinking of a functionality that people from different countries
> working
> together,could make reports and share these reports in one system, by
> giving
> link or sth. if ofbiz can generate pdf's on fly, it is better to
> share link
> to report than save pdf and send by email.
> ofbiz can translate labels in such reports, so why not to use it?
> i.e. if
> you generate report from sales with Russian locale and send me, I'll
> not be
> able to understand it. With this functionality you could send me a
> link to
> report and the report would be generated with polish locale and font,
> without any character breaks.
>
> Krzysztof Podejma
>
> 2007/6/28, Jacques Le Roux <[EMAIL PROTECTED]>:
> >
> > +1 to move this interesting issue to dev ML
> >
> > Jacques
> >
> > De : "Oleg Andreyev" <[EMAIL PROTECTED]>
> > > Hi Krzysztof,
> > >
> > > It's something wrong.
> > > To build multilanguage applications people invent UNICODE. To
> ensure
> > > unified look of a document anywhere Abobe was created Acrobat.
> > > Document created by FOP can be in any language (if used fonts
> have that
> > > language section of course). PDF in Polish with embed fonts
> remain
> > > readable anywhere.
> > >
> > > Current OfBiz reports have no instructions what fonts must be
> used. And
> > > it's bottom of the problem. Base-14 fonts must be available to
> every PDF
> > > reader but not any reader is localized. I think we have to select
> some
> > > widely used font (Å.g Arial, TTF I think as low overhead), modify
> > > reports to use it, add in trunk all required files. In this
> case we
> > > obtain printing that will work OOTB anywhere (I hope:-).
> > >
> > > What about move this thread to dev ML?
> > >
> > > Krzysztof Podejma ÐÉÛÅÔ:
> > > > thanks for the link I'll check it.
> > > >
> > > > I thought about font parameterizing for one greater purpose.
> Consider
> > > > multilingual system, now it is not possible to have reports in
> Chinese
> > ,
> > > > Russian, French etc. on one build(at once). If it would be
> possible to
> > > > associate font with locale and pass this font to reports, we
> would get
> > > > truly
> > > > multilingual system. No more broken encoding, automatic
> > document/report
> > > > translation and etc.
> > > > Of course this would require teplates(table size etc.) for
> fonts but
> > it
> > > > would work without it too.
> > > >
> > > > I have tested this and it works.
> > > >
> > > > placed
> > > > <#if (defaultFontFamily?exists)><#if (defaultFontFamily != "
> > > > pdf.default.fontfamily" && defaultFontFamily != "")>
> > > > font-family="${defaultFontFamily}" </#if></#if>
> > > > into <fo:page-sequence master-reference="main-page"> in
> > > > reportTemplate.fo.ftl
> > > >
> > > > <property-to-field field="defaultFontFamily" resource="general"
> > > > property="
> > > > pdf.default.fontfamily" default=""/>
> > > > into actions in FoReportDecorator
> > > >
> > > > pdf.default.fontfamily=Arial
> > > > into general.properties
> > > >
> > > > maybe it is not elegant but it works, test it with your font if
> you
> > like.
> > > >
> > > > Krzysztof Podejma
> > > >
> > > > 2007/6/28, Oleg Andreyev <[EMAIL PROTECTED]>:
> > > >>
> > > >>
> > > >>
> > > >> Krzysztof Podejma ÐÉÛÅÔ:
> > > >> > in trunk - current distribution default value would stay as
> it is
> > now,
> > > >> > and
> > > >> > nobody will change it to font that use metrics that aren't
> in
> > trunk.
> > > >> > I think it is good idea to change default font in one place
> instead
> > of
> > > >> > modifying all reports each.
> > > >> IMHO, for custom solutions replace works faster:) But you are
> right
> > on
> > > >> the whole.
> > > >> >
> > > >> > if you want to have more than one font in your pdf you can
> always
> > > >> > override a
> > > >> > font-family for block or for entire document.
> > > >> > this property would have ability to not take effect if not
> set
> > > >> >
> > > >> > Nobody wants to crash anything, we want to have less work
> because
> > > >> we use
> > > >> > non-English characters and it is a pain to track all new
> pdf's and
> > > >> > check if
> > > >> > they print correctly.
> > > >> >
> > > >> > +1 fop.xconf
> > > >> > AFAIK fop.xconf is necessary for custom fonts but you cannot
> set
> > > >> default
> > > >> > font in fop.xconf, correct me if I'm wrong
> > > >> http://xmlgraphics.apache.org/fop/0.93/fonts.html
> > > >> Pay attention to last topic. Theoretically if you have font
> Helvetica
> > > >> you can embed it as any other.
> > > >>
> > > >>
> > > >> > We need this property because we have fop.xconf and font
> metrics
> > > >> > installed
> > > >> > and we don't want to modify and/or merge all pdf files.
> > > >> >
> > > >> > Krzysztof Podejma
> > > >> >
> > > >> > 2007/6/27, Oleg Andreyev <[EMAIL PROTECTED]>:
> > > >> >>
> > > >> >> -1
> > > >> >> There are no universal solutions in this field.
> > > >> >> What's happened if somebody will add Arial(or Tahoma, or
> something
> > > >> else)
> > > >> >> as value this property in current distribution?
> > > >> >> Nothing. Just another error message in log.
> > > >> >> I have the same problems with Cyrillic fonts but apart from
> > > >> accessible
> > > >> >> programmatically default font name we need right fop.xconf,
> > > >> metrics and
> > > >> >> fonts itself installed in the system. Such property may be
> useful
> > > >> only
> > > >> >> if you well understand the rest configuration tasks. This
> is a
> > > >> point of
> > > >> >> mistake.
> > > >> >>
> > > >> >> As remark. I'd like to see standard fop.xconf in the trunk.
> One
> > from
> > > >> FOP
> > > >> >> distribution just well commented and can be used as guide
> by new
> > > >> users
> > > >> >> and developers.
> > > >> >> https://issues.apache.org/jira/browse/OFBIZ-990
> > > >> >>
> > > >> >> If fop.xconf will in trunk, it would be rightly move page
> > > >> height/width
> > > >> >> to config as part of the localization process. Now these
> hardcoded
> > > >> tags
> > > >> >> define Letter, not widely used paper format outside US.
> > > >> >>
> > > >> >>
> > > >> >> Krzysztof Podejma ÐÉÛÅÔ:
> > > >> >> > yes me too +1 general.properties with default fop font
> > > >> >> >
> > > >> >> >
> > > >> >> > 2007/6/27, Jacques Le Roux
> <[EMAIL PROTECTED]>:
> > > >> >> >>
> > > >> >> >> +1 for general.properties
> > > >> >> >>
> > > >> >> >> Jacques
> > > >> >> >>
> > > >> >> >> De : "Krzysztof Podejma" <[EMAIL PROTECTED]>
> > > >> >> >> > big thanks it works perfect.
>
=== message truncated ===
