[webERP -translation] TCPDF Fonts Behaviour and available Fonts: The Conclusion.

[Javier de Lorenzo-Cáceres]

#1.
TCPDF supports
TrueTypeUnicode, OpenTypeUnicode, TrueType, OpenType, Type1 and CID-0

TCPDF supports
embedding and not embedding fonts


#2.
That's not the whole truth. TCPDF is limited to the following:
(Please check it at tcpdf.php line 3068)

- TrueTypeUnicode, TrueType and Type1: They are always embedded.
- CID-0: It is never embedded.
- OpenType support is limited to TrueType.

Therefore, the use of a not embedded Unicode Font is not supported.
To use a not embedded font with TCPDF it must be CID
http://www.adobe.com/products/postscript/pdfs/cid.pdf


#3.
The following reach multilingual Unicode Fonts have all necessary
characters, glyphs, ideographs, etc. for global multilingual:

- Bitstream Cyberbit (13MB, Free, Serif) and
- Arial Unicode MS (23 MB, Propietary, Sans-Serif)

But to use them with TCPDF we have to embed them, i.e., we will get
a 13 MB or 23 MB pdf file.


#4.
If we choose not to embed them, they will treated as CID, TCPDF will
use a default uni2cid map and CID font on the client side will appear;
I call this a double substitution since the ANSI part will be substituted
by a client font and the international part will be substituted by another
client font, a client CID font.

Hence, when it comes to not embedded fonts, the font used in the server
side only determines the face style of the ANSI part and the uni2cid map
to use. It doesn't matter how reach is the font, most of its glyphs will be
lost.

I don't like pdf docs rendered with two types, I think they look horrible,
although, since it is rendered with client fonts, it may look different:

http://146.red-88-2-131.staticip.rima-tde.net/weberp311utf/javier/javier2.php

The font is Arial but my system subsitutes it
The ANSI part -> Arial
The CID part -> Kozuka Gothic Medium


#5.
To avoid the two types substitution I used Kozuka on the server side;
now the ANSI part looks the same that the CID part, both Kozuka.

http://146.red-88-2-131.staticip.rima-tde.net/weberp311utf/javier/javier11.php


#6.
As conversion from Unicode to CID is lossy, the correct CID font should be
selected to match the uni2cid map. The example above uses Kozuka which
is a CID font specially suited for Japanese UniJIS-UTF-16 so it matches the
Japanese uni2cid map (uni2cid_aj16.php) selected.

If they don't match (CID font and map) the result is a disaster,
the following example mix the same Japanese font with a Chinese GB map:
http://146.red-88-2-131.staticip.rima-tde.net/weberp311utf/javier/javier12.php

There are four maps: Chinese CN, Chinese GB, Korean and Japanese.

My CID fonts provided by Acrobat are limited to:
(Please check yours at C:\Program Files\Adobe\Acrobat\Resource\CIDFont)

- 6 Std fonts and
- 2 Pro fonts
 
Std stands for Standard and it means that it doesn't support the Central
Europe languages that Pro supports.

The 2 Pro fonts are the previous seen Kozuka Gothic Medium and Kozuka
Mincho Regular, the serif version of Kozuka:

http://146.red-88-2-131.staticip.rima-tde.net/weberp311utf/javier/javier13.php


#7.
For most languages, an Acrobat Pro font like Kozuka Gothic Pro Medium is
enough; although I prefer a Regular font (Bold > Medium > Regular > Light).

For Chinese or Korean alone, the Std fonts provided are enough,
The following example uses GB CID map with AdobeSongStd-Light font:
http://146.red-88-2-131.staticip.rima-tde.net/weberp311utf/javier/javier14.php

But for the use of one from the 4 CJK maps (like Chinese GB) along with the
international European characters (like German, Spanish or Turkish) that is
WGL4 (Windows Glyphs List 4)
http://www.microsoft.com/typography/unicode/cscp.htm
mixed in the same pdf doc, a Chinese Pro font is needed.

The need of a font not delivered with Acrobat has the
the disadvantage that it must be installed on client computers.


#8.
Not passed Test of 4 Arphic free fonts for Chinese

Traditional; missing all we need: Unified Ideographs, turkish and spanish,  and it's serif.
bkai00mp.ttf.gz, (AR PL KaitiM  Big5),    Kai Type Face, ZenKai-Medium
bsmi00lp.ttf.gz,  (AR PL Mingti2L Big5), Sung Type Face, ShanHeiSun-Light

Simplified; Unified Ideographs ok but missing turkish, spanish, and it's serif.
gkai00mp.ttf.gz, (AR PL KaitiM GB),  Kai Type Face, GBZenKai-Medium
gbsn00lp.ttf.gz,  (AR PL SungtiL GB), Sung Type Face, BousungEG-Light-GB


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

[Tim Schofield]

This isn't a subject I know a lot about so maybe this is a stupid
idea, but I was talking to someone the other day who told me that open
document format reports wouldn't have this problem. Now Microsoft
supports this format could we use odf instead of pdf??

Just tell em to go away if this is too stupid :-)

Tim


2009/8/10 AESE, S.L., Javier de Lorenzo-Cáceres. <info@...>:

> #1.
> TCPDF supports
> TrueTypeUnicode, OpenTypeUnicode, TrueType, OpenType, Type1 and CID-0
>
> TCPDF supports
> embedding and not embedding fonts
>
>
> #2.
> That's not the whole truth. TCPDF is limited to the following:
> (Please check it at tcpdf.php line 3068)
>
> - TrueTypeUnicode, TrueType and Type1: They are always embedded.
> - CID-0: It is never embedded.
> - OpenType support is limited to TrueType.
>
> Therefore, the use of a not embedded Unicode Font is not supported.
> To use a not embedded font with TCPDF it must be CID
> http://www.adobe.com/products/postscript/pdfs/cid.pdf
>
>
> #3.
> The following reach multilingual Unicode Fonts have all necessary
> characters, glyphs, ideographs, etc. for global multilingual:
>
> - Bitstream Cyberbit (13MB, Free, Serif) and
> - Arial Unicode MS (23 MB, Propietary, Sans-Serif)
>
> But to use them with TCPDF we have to embed them, i.e., we will get
> a 13 MB or 23 MB pdf file.
>
>
> #4.
> If we choose not to embed them, they will treated as CID, TCPDF will
> use a default uni2cid map and CID font on the client side will appear;
> I call this a double substitution since the ANSI part will be substituted
> by a client font and the international part will be substituted by another
> client font, a client CID font.
>
> Hence, when it comes to not embedded fonts, the font used in the server
> side only determines the face style of the ANSI part and the uni2cid map
> to use. It doesn't matter how reach is the font, most of its glyphs will be
> lost.
>
> I don't like pdf docs rendered with two types, I think they look horrible,
> although, since it is rendered with client fonts, it may look different:
>
> http://146.red-88-2-131.staticip.rima-tde.net/weberp311utf/javier/javier2.php
>
> The font is Arial but my system subsitutes it
> The ANSI part -> Arial
> The CID part -> Kozuka Gothic Medium
>
>
> #5.
> To avoid the two types substitution I used Kozuka on the server side;
> now the ANSI part looks the same that the CID part, both Kozuka.
>
> http://146.red-88-2-131.staticip.rima-tde.net/weberp311utf/javier/javier11.php
>
>
> #6.
> As conversion from Unicode to CID is lossy, the correct CID font should be
> selected to match the uni2cid map. The example above uses Kozuka which
> is a CID font specially suited for Japanese UniJIS-UTF-16 so it matches the
> Japanese uni2cid map (uni2cid_aj16.php) selected.
>
> If they don't match (CID font and map) the result is a disaster,
> the following example mix the same Japanese font with a Chinese GB map:
> http://146.red-88-2-131.staticip.rima-tde.net/weberp311utf/javier/javier12.php
>
> There are four maps: Chinese CN, Chinese GB, Korean and Japanese.
>
> My CID fonts provided by Acrobat are limited to:
> (Please check yours at C:\Program Files\Adobe\Acrobat\Resource\CIDFont)
>
> - 6 Std fonts and
> - 2 Pro fonts
>
> Std stands for Standard and it means that it doesn't support the Central
> Europe languages that Pro supports.
>
> The 2 Pro fonts are the previous seen Kozuka Gothic Medium and Kozuka
> Mincho Regular, the serif version of Kozuka:
>
> http://146.red-88-2-131.staticip.rima-tde.net/weberp311utf/javier/javier13.php
>
>
> #7.
> For most languages, an Acrobat Pro font like Kozuka Gothic Pro Medium is
> enough; although I prefer a Regular font (Bold > Medium > Regular > Light).
>
> For Chinese or Korean alone, the Std fonts provided are enough,
> The following example uses GB CID map with AdobeSongStd-Light font:
> http://146.red-88-2-131.staticip.rima-tde.net/weberp311utf/javier/javier14.php
>
> But for the use of one from the 4 CJK maps (like Chinese GB) along with the
> international European characters (like German, Spanish or Turkish) that is
> WGL4 (Windows Glyphs List 4)
> http://www.microsoft.com/typography/unicode/cscp.htm
> mixed in the same pdf doc, a Chinese Pro font is needed.
>
> The need of a font not delivered with Acrobat has the
> the disadvantage that it must be installed on client computers.
>
>
> #8.
> Not passed Test of 4 Arphic free fonts for Chinese
>
> Traditional; missing all we need: Unified Ideographs, turkish and spanish,  and it's serif.
> bkai00mp.ttf.gz, (AR PL KaitiM  Big5),    Kai Type Face, ZenKai-Medium
> bsmi00lp.ttf.gz,  (AR PL Mingti2L Big5), Sung Type Face, ShanHeiSun-Light
>
> Simplified; Unified Ideographs ok but missing turkish, spanish, and it's serif.
> gkai00mp.ttf.gz, (AR PL KaitiM GB),  Kai Type Face, GBZenKai-Medium
> gbsn00lp.ttf.gz,  (AR PL SungtiL GB), Sung Type Face, BousungEG-Light-GB
>
>
> 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 Tim:
This (yours) is an idea that has been bouncing inside my head too.
I've been concentrated in TCPDF last days and had no time to think on it,
indeed, I would like to do the final test to TCPDF before beggining to
think on any else.

I like odf because its ISO approval, its xml format and gzip compression.
All of this is very atractive to a web application.

The problem with odf  docs is a minor problem with web servers to treat
them as gzip (zip) files. They really are zip files but must be opened with
the
word processor not with an archive app like winzip from gzip or winrar.
The effect is also minor, it consist only that odf files from these
misconfigured
servers won't open in the browser window but they have to be locally saved
first, i.e, the browser plugin will fail with this kind of servers
(I'm not explaining well but I hope you know what I mean)

The web server right config to get odf opened in a browser, consist in
adding
the odf MIME type/s. to the "mime.types" conf file this way:

application/vnd.oasis.opendocument.text odt
application/vnd.oasis.opendocument.text-master odm
application/vnd.oasis.opendocument.text template ott
application/vnd.oasis.opendocument.text-web oth
application/vnd.oasis.opendocument.spreadsheet ods
application/vnd.oasis.opendocument.spreadsheet-template odm
...
image, presentation, graphics, formula, database,
etc. (indeed we only need the first line)

Warmest regards,
javier

----- Original Message -----
From: "Tim Schofield" <tim.schofield1960@...>
To: "Discussion of webERP translation issues"
<web-erp-translation@...>
Sent: Monday, August 10, 2009 12:07 PM
Subject: Re: [webERP -translation] TCPDF Fonts Behaviour and availableFonts:
The Conclusion.

> This isn't a subject I know a lot about so maybe this is a stupid
> idea, but I was talking to someone the other day who told me that open
> document format reports wouldn't have this problem. Now Microsoft
> supports this format could we use odf instead of pdf??
>
> Just tell em to go away if this is too stupid :-)
>
> Tim
>
>
> 2009/8/10 AESE, S.L., Javier de Lorenzo-Cáceres. <info@...>:
>> #1.
>> TCPDF supports
>> TrueTypeUnicode, OpenTypeUnicode, TrueType, OpenType, Type1 and CID-0
>>
>> TCPDF supports
>> embedding and not embedding fonts
>>
>>
>> #2.
>> That's not the whole truth. TCPDF is limited to the following:
>> (Please check it at tcpdf.php line 3068)
>>
>> - TrueTypeUnicode, TrueType and Type1: They are always embedded.
>> - CID-0: It is never embedded.
>> - OpenType support is limited to TrueType.
>>
>> Therefore, the use of a not embedded Unicode Font is not supported.
>> To use a not embedded font with TCPDF it must be CID
>> http://www.adobe.com/products/postscript/pdfs/cid.pdf
>>
>>
>> #3.
>> The following reach multilingual Unicode Fonts have all necessary
>> characters, glyphs, ideographs, etc. for global multilingual:
>>
>> - Bitstream Cyberbit (13MB, Free, Serif) and
>> - Arial Unicode MS (23 MB, Propietary, Sans-Serif)
>>
>> But to use them with TCPDF we have to embed them, i.e., we will get
>> a 13 MB or 23 MB pdf file.
>>
>>
>> #4.
>> If we choose not to embed them, they will treated as CID, TCPDF will
>> use a default uni2cid map and CID font on the client side will appear;
>> I call this a double substitution since the ANSI part will be substituted
>> by a client font and the international part will be substituted by
>> another
>> client font, a client CID font.
>>
>> Hence, when it comes to not embedded fonts, the font used in the server
>> side only determines the face style of the ANSI part and the uni2cid map
>> to use. It doesn't matter how reach is the font, most of its glyphs will
>> be
>> lost.
>>
>> I don't like pdf docs rendered with two types, I think they look
>> horrible,
>> although, since it is rendered with client fonts, it may look different:
>>
>> http://146.red-88-2-131.staticip.rima-tde.net/weberp311utf/javier/javier2.php
>>
>> The font is Arial but my system subsitutes it
>> The ANSI part -> Arial
>> The CID part -> Kozuka Gothic Medium
>>
>>
>> #5.
>> To avoid the two types substitution I used Kozuka on the server side;
>> now the ANSI part looks the same that the CID part, both Kozuka.
>>
>> http://146.red-88-2-131.staticip.rima-tde.net/weberp311utf/javier/javier11.php
>>
>>
>> #6.
>> As conversion from Unicode to CID is lossy, the correct CID font should
>> be
>> selected to match the uni2cid map. The example above uses Kozuka which
>> is a CID font specially suited for Japanese UniJIS-UTF-16 so it matches
>> the
>> Japanese uni2cid map (uni2cid_aj16.php) selected.
>>
>> If they don't match (CID font and map) the result is a disaster,
>> the following example mix the same Japanese font with a Chinese GB map:
>> http://146.red-88-2-131.staticip.rima-tde.net/weberp311utf/javier/javier12.php
>>
>> There are four maps: Chinese CN, Chinese GB, Korean and Japanese.
>>
>> My CID fonts provided by Acrobat are limited to:
>> (Please check yours at C:\Program Files\Adobe\Acrobat\Resource\CIDFont)
>>
>> - 6 Std fonts and
>> - 2 Pro fonts
>>
>> Std stands for Standard and it means that it doesn't support the Central
>> Europe languages that Pro supports.
>>
>> The 2 Pro fonts are the previous seen Kozuka Gothic Medium and Kozuka
>> Mincho Regular, the serif version of Kozuka:
>>
>> http://146.red-88-2-131.staticip.rima-tde.net/weberp311utf/javier/javier13.php
>>
>>
>> #7.
>> For most languages, an Acrobat Pro font like Kozuka Gothic Pro Medium is
>> enough; although I prefer a Regular font (Bold > Medium > Regular >
>> Light).
>>
>> For Chinese or Korean alone, the Std fonts provided are enough,
>> The following example uses GB CID map with AdobeSongStd-Light font:
>> http://146.red-88-2-131.staticip.rima-tde.net/weberp311utf/javier/javier14.php
>>
>> But for the use of one from the 4 CJK maps (like Chinese GB) along with
>> the
>> international European characters (like German, Spanish or Turkish) that
>> is
>> WGL4 (Windows Glyphs List 4)
>> http://www.microsoft.com/typography/unicode/cscp.htm
>> mixed in the same pdf doc, a Chinese Pro font is needed.
>>
>> The need of a font not delivered with Acrobat has the
>> the disadvantage that it must be installed on client computers.
>>
>>
>> #8.
>> Not passed Test of 4 Arphic free fonts for Chinese
>>
>> Traditional; missing all we need: Unified Ideographs, turkish and
>> spanish, and it's serif.
>> bkai00mp.ttf.gz, (AR PL KaitiM Big5), Kai Type Face, ZenKai-Medium
>> bsmi00lp.ttf.gz, (AR PL Mingti2L Big5), Sung Type Face, ShanHeiSun-Light
>>
>> Simplified; Unified Ideographs ok but missing turkish, spanish, and it's
>> serif.
>> gkai00mp.ttf.gz, (AR PL KaitiM GB), Kai Type Face, GBZenKai-Medium
>> gbsn00lp.ttf.gz, (AR PL SungtiL GB), Sung Type Face, BousungEG-Light-GB
>>
>>
>> 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

[Phil Daintree-3]

Not a bad idea!!

Tim Schofield wrote:

> This isn't a subject I know a lot about so maybe this is a stupid
> idea, but I was talking to someone the other day who told me that open
> document format reports wouldn't have this problem. Now Microsoft
> supports this format could we use odf instead of pdf??
>
> Just tell em to go away if this is too stupid :-)
>
> Tim
>
>
> 2009/8/10 AESE, S.L., Javier de Lorenzo-Cáceres. <info@...>:
>> #1.
>> TCPDF supports
>> TrueTypeUnicode, OpenTypeUnicode, TrueType, OpenType, Type1 and CID-0
>>
>> TCPDF supports
>> embedding and not embedding fonts
>>
>>
>> #2.
>> That's not the whole truth. TCPDF is limited to the following:
>> (Please check it at tcpdf.php line 3068)
>>
>> - TrueTypeUnicode, TrueType and Type1: They are always embedded.
>> - CID-0: It is never embedded.
>> - OpenType support is limited to TrueType.
>>
>> Therefore, the use of a not embedded Unicode Font is not supported.
>> To use a not embedded font with TCPDF it must be CID
>> http://www.adobe.com/products/postscript/pdfs/cid.pdf
>>
>>
>> #3.
>> The following reach multilingual Unicode Fonts have all necessary
>> characters, glyphs, ideographs, etc. for global multilingual:
>>
>> - Bitstream Cyberbit (13MB, Free, Serif) and
>> - Arial Unicode MS (23 MB, Propietary, Sans-Serif)
>>
>> But to use them with TCPDF we have to embed them, i.e., we will get
>> a 13 MB or 23 MB pdf file.
>>
>>
>> #4.
>> If we choose not to embed them, they will treated as CID, TCPDF will
>> use a default uni2cid map and CID font on the client side will appear;
>> I call this a double substitution since the ANSI part will be substituted
>> by a client font and the international part will be substituted by another
>> client font, a client CID font.
>>
>> Hence, when it comes to not embedded fonts, the font used in the server
>> side only determines the face style of the ANSI part and the uni2cid map
>> to use. It doesn't matter how reach is the font, most of its glyphs will be
>> lost.
>>
>> I don't like pdf docs rendered with two types, I think they look horrible,
>> although, since it is rendered with client fonts, it may look different:
>>
>> http://146.red-88-2-131.staticip.rima-tde.net/weberp311utf/javier/javier2.php
>>
>> The font is Arial but my system subsitutes it
>> The ANSI part -> Arial
>> The CID part -> Kozuka Gothic Medium
>>
>>
>> #5.
>> To avoid the two types substitution I used Kozuka on the server side;
>> now the ANSI part looks the same that the CID part, both Kozuka.
>>
>> http://146.red-88-2-131.staticip.rima-tde.net/weberp311utf/javier/javier11.php
>>
>>
>> #6.
>> As conversion from Unicode to CID is lossy, the correct CID font should be
>> selected to match the uni2cid map. The example above uses Kozuka which
>> is a CID font specially suited for Japanese UniJIS-UTF-16 so it matches the
>> Japanese uni2cid map (uni2cid_aj16.php) selected.
>>
>> If they don't match (CID font and map) the result is a disaster,
>> the following example mix the same Japanese font with a Chinese GB map:
>> http://146.red-88-2-131.staticip.rima-tde.net/weberp311utf/javier/javier12.php
>>
>> There are four maps: Chinese CN, Chinese GB, Korean and Japanese.
>>
>> My CID fonts provided by Acrobat are limited to:
>> (Please check yours at C:\Program Files\Adobe\Acrobat\Resource\CIDFont)
>>
>> - 6 Std fonts and
>> - 2 Pro fonts
>>
>> Std stands for Standard and it means that it doesn't support the Central
>> Europe languages that Pro supports.
>>
>> The 2 Pro fonts are the previous seen Kozuka Gothic Medium and Kozuka
>> Mincho Regular, the serif version of Kozuka:
>>
>> http://146.red-88-2-131.staticip.rima-tde.net/weberp311utf/javier/javier13.php
>>
>>
>> #7.
>> For most languages, an Acrobat Pro font like Kozuka Gothic Pro Medium is
>> enough; although I prefer a Regular font (Bold > Medium > Regular > Light).
>>
>> For Chinese or Korean alone, the Std fonts provided are enough,
>> The following example uses GB CID map with AdobeSongStd-Light font:
>> http://146.red-88-2-131.staticip.rima-tde.net/weberp311utf/javier/javier14.php
>>
>> But for the use of one from the 4 CJK maps (like Chinese GB) along with the
>> international European characters (like German, Spanish or Turkish) that is
>> WGL4 (Windows Glyphs List 4)
>> http://www.microsoft.com/typography/unicode/cscp.htm
>> mixed in the same pdf doc, a Chinese Pro font is needed.
>>
>> The need of a font not delivered with Acrobat has the
>> the disadvantage that it must be installed on client computers.
>>
>>
>> #8.
>> Not passed Test of 4 Arphic free fonts for Chinese
>>
>> Traditional; missing all we need: Unified Ideographs, turkish and spanish,  and it's serif.
>> bkai00mp.ttf.gz, (AR PL KaitiM  Big5),    Kai Type Face, ZenKai-Medium
>> bsmi00lp.ttf.gz,  (AR PL Mingti2L Big5), Sung Type Face, ShanHeiSun-Light
>>
>> Simplified; Unified Ideographs ok but missing turkish, spanish, and it's serif.
>> gkai00mp.ttf.gz, (AR PL KaitiM GB),  Kai Type Face, GBZenKai-Medium
>> gbsn00lp.ttf.gz,  (AR PL SungtiL GB), Sung Type Face, BousungEG-Light-GB
>>
>>
>> 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

[Harald Ringehahn ()]

Hola Javier, hi Phil, Tim and all others who contribute to webERP or just read this mailing list!
I have been very impressed by Javier's post as of August 4 (http://www.weberp.org/Internationalization) because of his intentions to get full internationalizaion and localization for webERP. I am not sure if our translation forum ist the right place, it is quite possible this topic is for delvelopers.
Let me put in my two cents please.
We have tried to analyze technical barriers in our system which manifest in permanent problems while printing pdf files. But I think, there is not only a technical problem but rather the problem to determine (and lay down) our needs.
When I brood about localization is there a jumble of (most conflicting) requirements by
1. conviniences for our users - nothing is more impedimental the system does not so like I want! -
2. legal requirements of companies we eye to - otherwise we could stop all work at this moment -
3. our efforts to accomodate our business partners where ever in the world.
It would not be successful to address all requirements at a single point within the system, we must sort our wishes and put them to the proper position.
The user wants the system speaks to him in his own language. User language is defined in www_users, ok so far, but localization also concerns date formats like YYYY-mm-dd, dd.mm.YYYY,  mm/dd/YYYY or dd/mm/YYYY (we have it one time in our system preferences) and number formats (we in Germany use comma as decimal sign and points as thousand separators - to have a change doesn't bear contemplating!).
The user wants to print his reports in his own language, but we have 1 (in words: one) helvetica.afm with one character set (which ever) in our fonts directory, haven't we? And we attempt to find out if tcpdf or open document format can help.
Our companies issue commercial papers like invoices, delivery slips and others. Should language and design of these depend on the language of the user who just pushes the button? No. This depends on the company and MUST be customizable, even you want to host systems for more than only your own enterprise.
And if we want to send a purchase order to our supplier or an order confirmation to our customer we could have the possibility to store their language in their master data.
Too much at once? Lets give it a serious consideration.
Harald

[Tim Schofield]

I agree with Harald's remarks. It is great to see so much effort and
knowledge going into the internationalization and localization
efforts.

Tim


2009/8/13 Harald Ringehahn <harald@...>:

>
> Hola Javier, hi Phil, Tim and all others who contribute to webERP or just
> read this mailing list!
> I have been very impressed by Javier's post as of August 5
> (http://www.nabble.com/Re%3A--webERP--translation--Recap-to24823875.html#a24831357)
> because of his intentions to get full internationalizaion and localization
> for webERP. I am not sure if our translation forum ist the right place, it
> is quite possible this topic is for delvelopers.
> Let me put in my two cents please.
> We have tried to analyze technical barriers in our system which manifest in
> permanent problems while printing pdf files. But I think, there is not only
> a technical problem but rather the problem to determine (and lay down) our
> needs.
> When I brood about localization is there a jumble of (most conflicting)
> requirements by
> 1. conviniences for our users - nothing is more impedimental the system does
> not so like I want! -
> 2. legal requirements of companies we eye to - otherwise we could stop all
> work at this moment -
> 3. our efforts to accomodate our business partners where ever in the world.
> It would not be successful to address all requirements at a single point
> within the system, we must sort our wishes and put them to the proper
> position.
> The user wants the system speaks to him in his own language. User language
> is defined in www_users, ok so far, but localization also concerns date
> formats like YYYY-mm-dd, dd.mm.YYYY,  mm/dd/YYYY or dd/mm/YYYY (we have it
> one time in our system preferences) and number formats (we in Germany use
> comma as decimal sign and points as thousand separators - to have a change
> doesn't bear contemplating!).
> The user wants to print his reports in his own language, but we have 1 (in
> words: one) helvetica.afm with one character set (which ever) in our fonts
> directory, haven't we? And we attempt to find out if tcpdf or open document
> format can help.
> Our companies issue commercial papers like invoices, delivery slips and
> others. Should language and design of these depend on the language of the
> user who just pushes the button? No. This depends on the company and MUST be
> customizable, even you want to host systems for more than only your own
> enterprise.
> And if we want to send a purchase order to our supplier or an order
> confirmation to our customer we could have the possibility to store their
> language in their master data.
> Too much at once? Lets give it a serious consideration.
> Harald
>
> --
> View this message in context: http://www.nabble.com/-webERP--translation--TCPDF-Fonts-Behaviour-and-available-Fonts%3A-The-Conclusion.-tp24897433p24953046.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