Re: [webERP -translation] Recap

[Phil Daintree-3]

Yes if we can make utf-8 pdfs without having to bundle the font then we
can simply change the whole system to use utf-8 and forget having to
change the character set. However, we need to prove the concept now with
TCPDF.

I am bit concerned that if a user does not have a system utf-8 font on
their machine then webERP reports will not work and now in addition to a
browser we have an additional dependency for webERP to work on client
machines - a utf-8 system font. This might be a show stopper for many?

Phil

AESE, S.L., Javier de Lorenzo-Cáceres. wrote:

> Hi Phil,
>  
> After reading a little bit more about pdf fonts I encountered people
> using more terms than concepts exist:
>  
> Terms: base fonts, core fonts, built-in fonts, embedded fonts, bundled
> fonts, system fonts.
>  
> Concepts: I think there are only 4 concepts,
> 1) System font: a font installed on the operating system.
> 2) Acrobat Base font: one of the 13 (or 14) Acrobat fonts not to
> embed for lightweight while maintaining interoperability and design
> fidelity (maybe we may use core fonts, built-in fonts or bundled
> fonts without the need of disambiguation from embedded fonts but we
> better avoid it).
> 3) MM font: Multiple Master font. I think these are two of the above,
> one serif and one sans-serif for substitution when a font not in the 13
> base fonts and not embedded is used (and maybe not in the target system).
> 4) Embedded font: the original font used in the original doc and
> embedded in the doc for 100% design fidelity everywhere (it may be a
> subset for lightweight).
>  
> You wrote:
> Seems extraordinary that the 35 Meg Adobe Acrobat doesn't have a utf-8
> font bundled??
>  
> I believe you are totally right: I'm reading that all are latin1 and it
> seems extraordinary, at least in recent versions.
>  
> Recap: Then, we must add another Advantage and correct nº2:
>  
> - New Advantage: pdf reports for all languages. (now they are latin1 + CJK)
> - Nº2: The use of full utf-8 (there is no need to develope an user
> option. There is no need to have a high speed connection, indeed, it
> will be more lightweight)
>  
> Recap: Moreover, we don´t need to think about conversion
> functions (Approach nº2)
>  
> Recap: now we are trying to achieve a real utf-8 compliant system. We
> must delete the word "prepared" in Advantage nº3. (neither we are trying
> to move iso dynamic change to the pdf generation stage.)
>  
> Recap: And maybe, to add a minor disadvantage: for all languages except
> english, utf-8 docs are a little bit bigger; this is specially true for
> CJK, but CJK will like to use it along other languages, for sure.
>  
> If this works, it will make many people happy. I think there are reasons
> to be excited about it.
> Moreover, it's an easier path than having to deal with creating a new
> user option and work with conversion (decode or transcode) functions.
>  
> ******************
> I think that now we may concentrate in:
> 1) What free open source library to use: we have TCPDF at hand.
> 2) How to "load" a system font in TCPDF (this must be an utf-8 font not
> in the 13 base fonts and not to embed).
> 3) Which font/s will be selected for best results of interoperabity,
> design fidelity, and viewing/printing quality (I have readed that Adobe
> Postscript Type 1 gives better results on screen than any other like
> Postscript Type 3 bitmapped fonts, PCL fonts, MacOS bitmap fonts,
> Windows vector (outline) fonts, etc.
>  
> Warmest regards,
> javier
>  
>  

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Web-ERP-translation mailing list
Web-ERP-translation@...
https://lists.sourceforge.net/lists/listinfo/web-erp-translation

[Javier de Lorenzo-Cáceres]

To make the story short
(Briefing for those that didn't have time to read the discussion)

* Intro
1) webERP is a very good i18n (internationalization) software but the pdf
reporting tool (FDPF) is only ISO-8859-1 + CJK (Chinese, Japanese and
Korean)

2) Some languages like Turkish not only lack the reporting tool (it shows a
blank page) but also have issues with htmlspecialchars and htmlentities php
functions.

** Moving to UTF-8
After the discussion that may be read, we now believe to have the path to
move to utf-8:
To avoid the unique utf-8 disadvantage of the very large pdf embedded utf-8
font/s, we are thinking on not to embed any font (If this fails, then we
would start to think on to embed a subset of the very large Unicode
characters repertoire).

This requires:
1) To replace FPDF by another free open-source pdf php class like TCPDF,
because FPDF doesn't have utf-8 support.
2) How to "load" the font to use.
3) Which font to use.
4) Font substitution (This is alike browsers behaviour)

*** Valuating

Disadvantages:
1) The client computer will do a font substitution since the font is not
embedded in the pdf report document.
2) The asian languages grows some weight (three bytes per character).
3) (maybe a little bit more complex php config).

Advantages:
1) global multilanguage on storage/screen/printer (everything utf-8, think
on multilanguage items list, clients, suppliers, etc.)
2) pdf reports for all languages (now they are latin1 + CJK)
3) Even more lightweight pdf reports as no fonts are embedded.
3) webERP sources in a really advanced state. More than i18n this must be
called simultaneous multilanguage.
4) No ISO charset dynamic change:
 - a) .po and translators not having to deal with charsets.
 - b) browsers not having to deal with iso changes.


The discussion is now at this point.

Yes if we can make utf-8 pdfs without having to bundle the font then we
can simply change the whole system to use utf-8 and forget having to
change the character set. However, we need to prove the concept now with
TCPDF.

I am bit concerned that if a user does not have a system utf-8 font on
their machine then webERP reports will not work and now in addition to a
browser we have an additional dependency for webERP to work on client
machines - a utf-8 system font. This might be a show stopper for many?

Phil

I comprehend that all preventions must be done before beginning to touch
sources. I agree with that.

A test might be done before doing anything else:
pdf docs might be created and sent to this list.

My thoughts,
Font substitution; that's the browser behaviour. Systems have improved their
inteligence at this point. At least the font to view the text on screen is
present for sure. Most recent systems like Linux or Vista have improved
utf-8 support and font substitution. I expect the normal case to be a matter
of fine tunning at design time, selecting the best font between many that
suite
the need.

For old systems like Windows XP, it's expected that the user has
his own language and fonts installed but it's normal that other
languages/fonts
must be installed. Normally, this is done by demand, when a user visits a
site,
the system ask/offer the user.

I also expect utf-8 fonts installed on client computers not to be
pan-Unicode.
As always, there will be special cases where an old system and a particular
combination of  languages will concur.

javier



------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Web-ERP-translation mailing list
Web-ERP-translation@...
https://lists.sourceforge.net/lists/listinfo/web-erp-translation

[mauro-36]

This is not concerniing the reports, but menues.
Is there a translation to spanish.
I am sorri if I drop in this way but I asked before and got no response.
If it is there were caon I find info to reed and set it up?
Thank you

Mauro Schiappa
Cucuta - Colombia


-----Mensaje original-----
De: AESE, S.L., Javier de Lorenzo-Cáceres. [mailto:info@...]
Enviado el: Miércoles, 05 de Agosto de 2009 10:56 a.m.
Para: Discussion of webERP translation issues
Asunto: [webERP -translation] From ISO to UTF-8 webERP Migration Plan

To make the story short
(Briefing for those that didn't have time to read the discussion)

* Intro
1) webERP is a very good i18n (internationalization) software but the pdf
reporting tool (FDPF) is only ISO-8859-1 + CJK (Chinese, Japanese and
Korean)

2) Some languages like Turkish not only lack the reporting tool (it shows a
blank page) but also have issues with htmlspecialchars and htmlentities php
functions.

** Moving to UTF-8
After the discussion that may be read, we now believe to have the path to
move to utf-8:
To avoid the unique utf-8 disadvantage of the very large pdf embedded utf-8
font/s, we are thinking on not to embed any font (If this fails, then we
would start to think on to embed a subset of the very large Unicode
characters repertoire).

This requires:
1) To replace FPDF by another free open-source pdf php class like TCPDF,
because FPDF doesn't have utf-8 support.
2) How to "load" the font to use.
3) Which font to use.
4) Font substitution (This is alike browsers behaviour)

*** Valuating

Disadvantages:
1) The client computer will do a font substitution since the font is not
embedded in the pdf report document.
2) The asian languages grows some weight (three bytes per character).
3) (maybe a little bit more complex php config).

Advantages:
1) global multilanguage on storage/screen/printer (everything utf-8, think
on multilanguage items list, clients, suppliers, etc.)
2) pdf reports for all languages (now they are latin1 + CJK)
3) Even more lightweight pdf reports as no fonts are embedded.
3) webERP sources in a really advanced state. More than i18n this must be
called simultaneous multilanguage.
4) No ISO charset dynamic change:
 - a) .po and translators not having to deal with charsets.
 - b) browsers not having to deal with iso changes.


The discussion is now at this point.

Yes if we can make utf-8 pdfs without having to bundle the font then we
can simply change the whole system to use utf-8 and forget having to
change the character set. However, we need to prove the concept now with
TCPDF.

I am bit concerned that if a user does not have a system utf-8 font on
their machine then webERP reports will not work and now in addition to a
browser we have an additional dependency for webERP to work on client
machines - a utf-8 system font. This might be a show stopper for many?

Phil

I comprehend that all preventions must be done before beginning to touch
sources. I agree with that.

A test might be done before doing anything else:
pdf docs might be created and sent to this list.

My thoughts,
Font substitution; that's the browser behaviour. Systems have improved their
inteligence at this point. At least the font to view the text on screen is
present for sure. Most recent systems like Linux or Vista have improved
utf-8 support and font substitution. I expect the normal case to be a matter
of fine tunning at design time, selecting the best font between many that
suite
the need.

For old systems like Windows XP, it's expected that the user has
his own language and fonts installed but it's normal that other
languages/fonts
must be installed. Normally, this is done by demand, when a user visits a
site,
the system ask/offer the user.

I also expect utf-8 fonts installed on client computers not to be
pan-Unicode.
As always, there will be special cases where an old system and a particular
combination of  languages will concur.

javier



----------------------------------------------------------------------------
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus
on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Web-ERP-translation mailing list
Web-ERP-translation@...
https://lists.sourceforge.net/lists/listinfo/web-erp-translation


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Web-ERP-translation mailing list
Web-ERP-translation@...
https://lists.sourceforge.net/lists/listinfo/web-erp-translation

[Javier de Lorenzo-Cáceres]

Hi Mauro
This is the correct site to ask. There are several translations to spanish,
they differ in the country they are suited for, the translators that
maintain
them, some writing style like the use of html entities and the percentage
of strings translated/not translated yet, between others.

You may download one or all at sourceforge webERP's site (look at files).
Feel free to ask if this is not the response you expected for.

Regards,
javier

----- Original Message -----
From: <mauro@...>
To: "'Discussion of webERP translation issues'"
<web-erp-translation@...>
Sent: Wednesday, August 05, 2009 5:50 PM
Subject: Re: [webERP -translation] From ISO to UTF-8 webERP Migration Plan


This is not concerniing the reports, but menues.
Is there a translation to spanish.
I am sorri if I drop in this way but I asked before and got no response.
If it is there were caon I find info to reed and set it up?
Thank you

Mauro Schiappa
Cucuta - Colombia


-----Mensaje original-----
De: AESE, S.L., Javier de Lorenzo-Cáceres. [mailto:info@...]
Enviado el: Miércoles, 05 de Agosto de 2009 10:56 a.m.
Para: Discussion of webERP translation issues
Asunto: [webERP -translation] From ISO to UTF-8 webERP Migration Plan

To make the story short
(Briefing for those that didn't have time to read the discussion)

* Intro
1) webERP is a very good i18n (internationalization) software but the pdf
reporting tool (FDPF) is only ISO-8859-1 + CJK (Chinese, Japanese and
Korean)

2) Some languages like Turkish not only lack the reporting tool (it shows a
blank page) but also have issues with htmlspecialchars and htmlentities php
functions.

** Moving to UTF-8
After the discussion that may be read, we now believe to have the path to
move to utf-8:
To avoid the unique utf-8 disadvantage of the very large pdf embedded utf-8
font/s, we are thinking on not to embed any font (If this fails, then we
would start to think on to embed a subset of the very large Unicode
characters repertoire).

This requires:
1) To replace FPDF by another free open-source pdf php class like TCPDF,
because FPDF doesn't have utf-8 support.
2) How to "load" the font to use.
3) Which font to use.
4) Font substitution (This is alike browsers behaviour)

*** Valuating

Disadvantages:
1) The client computer will do a font substitution since the font is not
embedded in the pdf report document.
2) The asian languages grows some weight (three bytes per character).
3) (maybe a little bit more complex php config).

Advantages:
1) global multilanguage on storage/screen/printer (everything utf-8, think
on multilanguage items list, clients, suppliers, etc.)
2) pdf reports for all languages (now they are latin1 + CJK)
3) Even more lightweight pdf reports as no fonts are embedded.
3) webERP sources in a really advanced state. More than i18n this must be
called simultaneous multilanguage.
4) No ISO charset dynamic change:
 - a) .po and translators not having to deal with charsets.
 - b) browsers not having to deal with iso changes.


The discussion is now at this point.

Yes if we can make utf-8 pdfs without having to bundle the font then we
can simply change the whole system to use utf-8 and forget having to
change the character set. However, we need to prove the concept now with
TCPDF.

I am bit concerned that if a user does not have a system utf-8 font on
their machine then webERP reports will not work and now in addition to a
browser we have an additional dependency for webERP to work on client
machines - a utf-8 system font. This might be a show stopper for many?

Phil

I comprehend that all preventions must be done before beginning to touch
sources. I agree with that.

A test might be done before doing anything else:
pdf docs might be created and sent to this list.

My thoughts,
Font substitution; that's the browser behaviour. Systems have improved their
inteligence at this point. At least the font to view the text on screen is
present for sure. Most recent systems like Linux or Vista have improved
utf-8 support and font substitution. I expect the normal case to be a matter
of fine tunning at design time, selecting the best font between many that
suite
the need.

For old systems like Windows XP, it's expected that the user has
his own language and fonts installed but it's normal that other
languages/fonts
must be installed. Normally, this is done by demand, when a user visits a
site,
the system ask/offer the user.

I also expect utf-8 fonts installed on client computers not to be
pan-Unicode.
As always, there will be special cases where an old system and a particular
combination of  languages will concur.

javier



----------------------------------------------------------------------------
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus
on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Web-ERP-translation mailing list
Web-ERP-translation@...
https://lists.sourceforge.net/lists/listinfo/web-erp-translation


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus
on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Web-ERP-translation mailing list
Web-ERP-translation@...
https://lists.sourceforge.net/lists/listinfo/web-erp-translation



------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Web-ERP-translation mailing list
Web-ERP-translation@...
https://lists.sourceforge.net/lists/listinfo/web-erp-translation

[mauro-36]

Thank you,
I have downloaded the file es_CO-3.10 , unpacked it and copied in the
directory /weberp/locale/es_co .  After setting the user up I was able to
select the language for the new user, however it does not work.
Is there any additional change I need to make before it will work??

Thank you again.

Mauro

-----Mensaje original-----
De: AESE, S.L., Javier de Lorenzo-Cáceres. [mailto:info@...]
Enviado el: Miércoles, 05 de Agosto de 2009 12:53 p.m.
Para: Discussion of webERP translation issues
Asunto: Re: [webERP -translation] From ISO to UTF-8 webERP Migration Plan

Hi Mauro
This is the correct site to ask. There are several translations to spanish,
they differ in the country they are suited for, the translators that
maintain
them, some writing style like the use of html entities and the percentage
of strings translated/not translated yet, between others.

You may download one or all at sourceforge webERP's site (look at files).
Feel free to ask if this is not the response you expected for.

Regards,
javier

----- Original Message -----
From: <mauro@...>
To: "'Discussion of webERP translation issues'"
<web-erp-translation@...>
Sent: Wednesday, August 05, 2009 5:50 PM
Subject: Re: [webERP -translation] From ISO to UTF-8 webERP Migration Plan


This is not concerniing the reports, but menues.
Is there a translation to spanish.
I am sorri if I drop in this way but I asked before and got no response.
If it is there were caon I find info to reed and set it up?
Thank you

Mauro Schiappa
Cucuta - Colombia


-----Mensaje original-----
De: AESE, S.L., Javier de Lorenzo-Cáceres. [mailto:info@...]
Enviado el: Miércoles, 05 de Agosto de 2009 10:56 a.m.
Para: Discussion of webERP translation issues
Asunto: [webERP -translation] From ISO to UTF-8 webERP Migration Plan

To make the story short
(Briefing for those that didn't have time to read the discussion)

* Intro
1) webERP is a very good i18n (internationalization) software but the pdf
reporting tool (FDPF) is only ISO-8859-1 + CJK (Chinese, Japanese and
Korean)

2) Some languages like Turkish not only lack the reporting tool (it shows a
blank page) but also have issues with htmlspecialchars and htmlentities php
functions.

** Moving to UTF-8
After the discussion that may be read, we now believe to have the path to
move to utf-8:
To avoid the unique utf-8 disadvantage of the very large pdf embedded utf-8
font/s, we are thinking on not to embed any font (If this fails, then we
would start to think on to embed a subset of the very large Unicode
characters repertoire).

This requires:
1) To replace FPDF by another free open-source pdf php class like TCPDF,
because FPDF doesn't have utf-8 support.
2) How to "load" the font to use.
3) Which font to use.
4) Font substitution (This is alike browsers behaviour)

*** Valuating

Disadvantages:
1) The client computer will do a font substitution since the font is not
embedded in the pdf report document.
2) The asian languages grows some weight (three bytes per character).
3) (maybe a little bit more complex php config).

Advantages:
1) global multilanguage on storage/screen/printer (everything utf-8, think
on multilanguage items list, clients, suppliers, etc.)
2) pdf reports for all languages (now they are latin1 + CJK)
3) Even more lightweight pdf reports as no fonts are embedded.
3) webERP sources in a really advanced state. More than i18n this must be
called simultaneous multilanguage.
4) No ISO charset dynamic change:
 - a) .po and translators not having to deal with charsets.
 - b) browsers not having to deal with iso changes.


The discussion is now at this point.

Yes if we can make utf-8 pdfs without having to bundle the font then we
can simply change the whole system to use utf-8 and forget having to
change the character set. However, we need to prove the concept now with
TCPDF.

I am bit concerned that if a user does not have a system utf-8 font on
their machine then webERP reports will not work and now in addition to a
browser we have an additional dependency for webERP to work on client
machines - a utf-8 system font. This might be a show stopper for many?

Phil

I comprehend that all preventions must be done before beginning to touch
sources. I agree with that.

A test might be done before doing anything else:
pdf docs might be created and sent to this list.

My thoughts,
Font substitution; that's the browser behaviour. Systems have improved their
inteligence at this point. At least the font to view the text on screen is
present for sure. Most recent systems like Linux or Vista have improved
utf-8 support and font substitution. I expect the normal case to be a matter
of fine tunning at design time, selecting the best font between many that
suite
the need.

For old systems like Windows XP, it's expected that the user has
his own language and fonts installed but it's normal that other
languages/fonts
must be installed. Normally, this is done by demand, when a user visits a
site,
the system ask/offer the user.

I also expect utf-8 fonts installed on client computers not to be
pan-Unicode.
As always, there will be special cases where an old system and a particular
combination of  languages will concur.

javier



----------------------------------------------------------------------------
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus
on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Web-ERP-translation mailing list
Web-ERP-translation@...
https://lists.sourceforge.net/lists/listinfo/web-erp-translation


----------------------------------------------------------------------------
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus
on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Web-ERP-translation mailing list
Web-ERP-translation@...
https://lists.sourceforge.net/lists/listinfo/web-erp-translation



----------------------------------------------------------------------------
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus
on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Web-ERP-translation mailing list
Web-ERP-translation@...
https://lists.sourceforge.net/lists/listinfo/web-erp-translation


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Web-ERP-translation mailing list
Web-ERP-translation@...
https://lists.sourceforge.net/lists/listinfo/web-erp-translation

[Javier de Lorenzo-Cáceres]

Hi Mauro,

1) Be sure the path is  YourWebERPdir/locale/es_CO/LC_MESSAGES/messages.mo
Note the capitalization, you must respect uppercase characters.

2) If you are using Linux, be sure you have this locale installed on your
O.S.

3) Be sure your web server have gettext installed. webERP has an alternative
but I don't know about it because gettext is the way to go.

4) Then restart your web server (I'm not sure of the behaviour of the
compiled binary file, sometimes it picks and sometimes not.)

This above is just what I did.

Suerte,
javier


----- Original Message -----
From: <mauro@...>
To: "'Discussion of webERP translation issues'"
<web-erp-translation@...>
Sent: Wednesday, August 05, 2009 9:39 PM
Subject: Re: [webERP -translation] From ISO to UTF-8 webERP Migration Plan


Thank you,
I have downloaded the file es_CO-3.10 , unpacked it and copied in the
directory /weberp/locale/es_co .  After setting the user up I was able to
select the language for the new user, however it does not work.
Is there any additional change I need to make before it will work??

Thank you again.

Mauro

-----Mensaje original-----
De: AESE, S.L., Javier de Lorenzo-Cáceres. [mailto:info@...]
Enviado el: Miércoles, 05 de Agosto de 2009 12:53 p.m.
Para: Discussion of webERP translation issues
Asunto: Re: [webERP -translation] From ISO to UTF-8 webERP Migration Plan

Hi Mauro
This is the correct site to ask. There are several translations to spanish,
they differ in the country they are suited for, the translators that
maintain
them, some writing style like the use of html entities and the percentage
of strings translated/not translated yet, between others.

You may download one or all at sourceforge webERP's site (look at files).
Feel free to ask if this is not the response you expected for.

Regards,
javier

----- Original Message -----
From: <mauro@...>
To: "'Discussion of webERP translation issues'"
<web-erp-translation@...>
Sent: Wednesday, August 05, 2009 5:50 PM
Subject: Re: [webERP -translation] From ISO to UTF-8 webERP Migration Plan


This is not concerniing the reports, but menues.
Is there a translation to spanish.
I am sorri if I drop in this way but I asked before and got no response.
If it is there were caon I find info to reed and set it up?
Thank you

Mauro Schiappa
Cucuta - Colombia


-----Mensaje original-----
De: AESE, S.L., Javier de Lorenzo-Cáceres. [mailto:info@...]
Enviado el: Miércoles, 05 de Agosto de 2009 10:56 a.m.
Para: Discussion of webERP translation issues
Asunto: [webERP -translation] From ISO to UTF-8 webERP Migration Plan

To make the story short
(Briefing for those that didn't have time to read the discussion)

* Intro
1) webERP is a very good i18n (internationalization) software but the pdf
reporting tool (FDPF) is only ISO-8859-1 + CJK (Chinese, Japanese and
Korean)

2) Some languages like Turkish not only lack the reporting tool (it shows a
blank page) but also have issues with htmlspecialchars and htmlentities php
functions.

** Moving to UTF-8
After the discussion that may be read, we now believe to have the path to
move to utf-8:
To avoid the unique utf-8 disadvantage of the very large pdf embedded utf-8
font/s, we are thinking on not to embed any font (If this fails, then we
would start to think on to embed a subset of the very large Unicode
characters repertoire).

This requires:
1) To replace FPDF by another free open-source pdf php class like TCPDF,
because FPDF doesn't have utf-8 support.
2) How to "load" the font to use.
3) Which font to use.
4) Font substitution (This is alike browsers behaviour)

*** Valuating

Disadvantages:
1) The client computer will do a font substitution since the font is not
embedded in the pdf report document.
2) The asian languages grows some weight (three bytes per character).
3) (maybe a little bit more complex php config).

Advantages:
1) global multilanguage on storage/screen/printer (everything utf-8, think
on multilanguage items list, clients, suppliers, etc.)
2) pdf reports for all languages (now they are latin1 + CJK)
3) Even more lightweight pdf reports as no fonts are embedded.
3) webERP sources in a really advanced state. More than i18n this must be
called simultaneous multilanguage.
4) No ISO charset dynamic change:
 - a) .po and translators not having to deal with charsets.
 - b) browsers not having to deal with iso changes.


The discussion is now at this point.

Yes if we can make utf-8 pdfs without having to bundle the font then we
can simply change the whole system to use utf-8 and forget having to
change the character set. However, we need to prove the concept now with
TCPDF.

I am bit concerned that if a user does not have a system utf-8 font on
their machine then webERP reports will not work and now in addition to a
browser we have an additional dependency for webERP to work on client
machines - a utf-8 system font. This might be a show stopper for many?

Phil

I comprehend that all preventions must be done before beginning to touch
sources. I agree with that.

A test might be done before doing anything else:
pdf docs might be created and sent to this list.

My thoughts,
Font substitution; that's the browser behaviour. Systems have improved their
inteligence at this point. At least the font to view the text on screen is
present for sure. Most recent systems like Linux or Vista have improved
utf-8 support and font substitution. I expect the normal case to be a matter
of fine tunning at design time, selecting the best font between many that
suite
the need.

For old systems like Windows XP, it's expected that the user has
his own language and fonts installed but it's normal that other
languages/fonts
must be installed. Normally, this is done by demand, when a user visits a
site,
the system ask/offer the user.

I also expect utf-8 fonts installed on client computers not to be
pan-Unicode.
As always, there will be special cases where an old system and a particular
combination of  languages will concur.

javier



----------------------------------------------------------------------------
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus
on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Web-ERP-translation mailing list
Web-ERP-translation@...
https://lists.sourceforge.net/lists/listinfo/web-erp-translation


----------------------------------------------------------------------------
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus
on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Web-ERP-translation mailing list
Web-ERP-translation@...
https://lists.sourceforge.net/lists/listinfo/web-erp-translation



----------------------------------------------------------------------------
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus
on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Web-ERP-translation mailing list
Web-ERP-translation@...
https://lists.sourceforge.net/lists/listinfo/web-erp-translation


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus
on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Web-ERP-translation mailing list
Web-ERP-translation@...
https://lists.sourceforge.net/lists/listinfo/web-erp-translation



------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Web-ERP-translation mailing list
Web-ERP-translation@...
https://lists.sourceforge.net/lists/listinfo/web-erp-translation

[Harald Ringehahn]

I stopped to tryout tcpdf about a year ago, but it seems the only way to get agreeable printout. I stopped because a vision, to put it simply, it was too tremendous for me:
Imagine you have a form. It has a Header, perhaps one for a first page and another for following ones. You have areas for address fields of your business partners, you find headers for tables, elements for tablerows, possibly separate for even and odd line numbers, for subtotals, totals and so on.
And every time you print a form as pdf your script looks in the /companies/[name]/forms folder if there is such a special element and otherwise we take a default sequence within the script.
I had a dream - until now. If we change the pdf scripts anyway we should retain it in our mind.
What sense or nonsense is it?
Harald

[Javier de Lorenzo-Cáceres]

----- Original Message -----
From: "Harald Ringehahn" <harald@...>
To: <web-erp-translation@...>
Sent: Thursday, August 06, 2009 8:16 PM
Subject: Re: [webERP -translation] Recap


>
> I stopped to tryout tcpdf about a year ago, but it seems the only way to
> get
> agreeable printout. I stopped because a vision, to put it simply, it was
> too
> tremendous for me:
> Imagine you have a form. It has a Header,

ups! you mean a report (or a form that generates a report); right?

> perhaps one for a first page and
> another for following ones. You have areas for address fields of your
> business partners, you find headers for tables, elements for tablerows,
> possibly separate for even and odd line numbers, for subtotals, totals and
> so on.

this is what reports are, I'm sure.

> And every time you print a form as pdf

you did it again; are you sure it is about printing forms?

> your script looks in the
> /companies/[name]/forms folder if there is such a special element and
> otherwise we take a default sequence within the script.
> I had a dream - until now. If we change the pdf scripts anyway we should
> retain it in our mind.
> What sense or nonsense is it?
> Harald
> --

uf, I'm lost, sorry.

> View this message in context:
> http://www.nabble.com/Re%3A--webERP--translation--Recap-tp24823875p24852722.html
> Sent from the web-erp-translation mailing list archive at Nabble.com.
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
> 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Web-ERP-translation mailing list
> Web-ERP-translation@...
> https://lists.sourceforge.net/lists/listinfo/web-erp-translation
>

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Web-ERP-translation mailing list
Web-ERP-translation@...
https://lists.sourceforge.net/lists/listinfo/web-erp-translation