[webERP -translation] CID update
|
View:
New views
8 Messages
—
Rating Filter:
Alert me
|
 |
[webERP -translation] CID update
by Javier de Lorenzo-Cáceres
::
Rate this Message:
I have been doing a lot of corrections to our CID reference page. I would like it to be in webERP.org but it needs UTF-8. I uploaded it to
http://www.civicom.eu/cuestore/examples.htm (although pdf remains generating from the same slow testing PC) But the most important quid is that it argues that a CMap alone doesn't solve the trick for Chinese+Turkish (path to the solution is also argued) and that this should not be a break, because from 18 webERP languages (English + translations), by now, 7 are not supported by both fpdf and php htmlspecialchars function, i.e., now there is no Turkish pdf at all (and Czech, Hungarian, Polish, Russian, Greek and Persian are in the same situation). regards, javier P.D. (I still need to correct some things like example 2 files size cause I changed sample texts too, and also I want to upload odts to show the behaviour of the abscence of OOo Mime Types.) ------------------------------------------------------------------------------ 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 |
|
|
Re: [webERP -translation] CID update
by Cesure.CN
::
Rate this Message:
Hi Javier,
It's very instructive! Wish that 3.11 could switch to tcpdf.  Thanks & warmest regards, -Zhiguo
|
|
|
Re: [webERP -translation] CID update
by Phil Daintree-3
::
Rate this Message:
Crickey, this is hard stuff! You have done an amazing job trying to find
a solution for us. I am not sure I understood all of the text at > http://www.civicom.eu/cuestore/examples.htm but ... it seems that CID whilst it has the advantage of not having to send an embedded font with the report and clog up a slow connection, the CIDs are not unique and the same CID is used by a number of different character sets and there is overlap between character sets so you could get unpredictable results? I think??? So we have a dead end?? ...things are just not that easy with pdfs :-( One other snag with open document format is that it does not allow for precise positioning of text and graphics on a page, or does it?? I am not sure if it matters that there is no browser plugin for open document format - as long as we can download it into an external application and have a mime type for the file of the report being downloaded so we can open it automatically in the external program... this is the recommended way of running pdf reports too. I still can't see a way forward with this... Phil AESE, S.L., Javier de Lorenzo-Cáceres. wrote: > I have been doing a lot of corrections to our CID reference page. I would like it to be in webERP.org but it needs UTF-8. I uploaded it to > > http://www.civicom.eu/cuestore/examples.htm > > (although pdf remains generating from the same slow testing PC) > > But the most important quid is that it argues that a CMap alone doesn't solve the trick for Chinese+Turkish (path to the solution is also argued) and that this should not be a break, because from 18 webERP languages (English + translations), by now, 7 are not supported by both fpdf and php htmlspecialchars function, i.e., now there is no Turkish pdf at all (and Czech, Hungarian, Polish, Russian, Greek and Persian are in the same situation). > > regards, > javier > > > P.D. > (I still need to correct some things like example 2 files size cause I changed sample texts too, and also I want to upload odts to show the behaviour of the abscence of OOo Mime Types.) > ------------------------------------------------------------------------------ > 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 |
|
|
Re: [webERP -translation] CID update
by Tim Schofield
::
Rate this Message:
Hi, regarding using open document there is this library here:
http://www.odtphp.com/ that allows you to create odt templates with tags in and then just replace the tags with values in the php script. This would enable people to create their own layouts without having to change the code. Thanks Tim 2009/8/22 Phil Daintree <phil@...>: > Crickey, this is hard stuff! You have done an amazing job trying to find > a solution for us. I am not sure I understood all of the text at > > > http://www.civicom.eu/cuestore/examples.htm > > but ... it seems that CID whilst it has the advantage of not having to > send an embedded font with the report and clog up a slow connection, the > CIDs are not unique and the same CID is used by a number of different > character sets and there is overlap between character sets so you could > get unpredictable results? I think??? > > So we have a dead end?? ...things are just not that easy with pdfs :-( > > One other snag with open document format is that it does not allow for > precise positioning of text and graphics on a page, or does it?? > > I am not sure if it matters that there is no browser plugin for open > document format - as long as we can download it into an external > application and have a mime type for the file of the report being > downloaded so we can open it automatically in the external program... > this is the recommended way of running pdf reports too. > > I still can't see a way forward with this... > > Phil > > AESE, S.L., Javier de Lorenzo-Cáceres. wrote: >> I have been doing a lot of corrections to our CID reference page. I would like it to be in webERP.org but it needs UTF-8. I uploaded it to >> >> http://www.civicom.eu/cuestore/examples.htm >> >> (although pdf remains generating from the same slow testing PC) >> >> But the most important quid is that it argues that a CMap alone doesn't solve the trick for Chinese+Turkish (path to the solution is also argued) and that this should not be a break, because from 18 webERP languages (English + translations), by now, 7 are not supported by both fpdf and php htmlspecialchars function, i.e., now there is no Turkish pdf at all (and Czech, Hungarian, Polish, Russian, Greek and Persian are in the same situation). >> >> regards, >> javier >> >> >> P.D. >> (I still need to correct some things like example 2 files size cause I changed sample texts too, and also I want to upload odts to show the behaviour of the abscence of OOo Mime Types.) >> ------------------------------------------------------------------------------ >> 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 |
|
|
Re: [webERP -translation] CID update
by Javier de Lorenzo-Cáceres
::
Rate this Message:
I'll try to explain better, please read below,
> Crickey, this is hard stuff! You have done an amazing job trying to find > a solution for us. I am not sure I understood all of the text at > http://www.civicom.eu/cuestore/examples.htm > but ... it seems that CID whilst it has the advantage of not having to > send an embedded font with the report and clog up a slow connection, the > CIDs are not unique and the same CID is used by a number of different > character sets The CID advantage over ISO is: CID is 16 bits while ISO is 8 bits. This is a great advantage, it allows very large character collections, up to 65536, comparing to 256. This large collections can cover several character sets, for example, collection Adobe-Japan1-6 covers Japan, Western, Central Europe, Chinese, etc. This collection is about 30,000 so it has room for other 35,000 Adobe forgot? to include Unified Ideograph; I guess there may be political or economic reasons to do it this way; or simply Adobe thought that this is not necessary because Chinese is now included, Unified Ideograph is not needed (please read improvement #4 below). Another advantage is that collections may be used at time. Adobe decided to not make a very big collection. Adobe's design is about 4 or 5 collections: CCJK V > and there is overlap between character sets Yes, it is similar than ISO, for example, with ISO, if a turkish person writes in a text file a "dotted I" and send it to me, I see a "Y with acute" because he is using ISO-9 and I'm using ISO-15 and what is sent is a byte with value 0xDD where, you know, 0x means hex so D = 1101 = 13, DD = 11011101 = 221 i.e., he sends me a byte with value 221 . Beyond the language, the charset ID is needed to decode 221 to the truly "dotted I". Language="Turkish" is not enough because there are 2 ISO Charsets that supports Turkish. The problem is that text files don't have a header for this, as html and other files do. With CID happens somethig "similar", 2105 corresponds to different glyphs in diferrent collections but here there is no problem, because pdf is even more advanced that html headers. With html header you declare the charset for the whole file; here you can use several charsets within a file. > so you could > get unpredictable results? I think??? Nope. There is no ambiguos stuff like in the above example when a turkish person sent me a text text file . I think you refer to the example I made to show that CIDFont and CMaps must match. I made it to show that sometimes things are not easy to explain: Adobe says that CIDFont can share CMaps. That's true: "CIDFonts can share CMaps". But maybe the reader didn't read all that was said before about collections and this might be misunderstood. Hence, accuracy: "CIDFonts can share CMaps within the boundaries of a specific collection". i.e., "Not every CIDFont works with every CMap". Indeed if CMaps were happily shared there would not be such amount in CMap folder, there are lots of CMaps and only a few fonts. >So we have a dead end?? I know my english is bad but, As bad did I explain it? TCPDF is a very good improvement. Let's say that it's not what we expected. We thought something like "let's use utf-8 to make webERP multilanguage and forget about charsets and issues with pdf and php functions". I'll try to explain how TCPDF will enhance webERP: 1) Forget about charset dynamic change. 2) Forget about php htmlspecialchars() issues. 3) FPDF doesn't allow pdf reports for: Turkish, Czech, Hungarian, Polish, Russian, Greek and Persian webERP translations; TCPDF will do it. 4) Languages: 4a) FPDF multilanguage is limited to ISO-1 (9 languages), TCPDF will cover all 18 (all webERP translations), more precise, Chinese is included, the issue is about the Unified Ideograph range. I guess the Unified Ideograph is a set of glyphs developed to make a common space for Asians languages, i.e., since it was not possible to have 2 from Japanese-Chinese-Korean-Vietnamese languages in 256 glyphs (1-byte values) this limitation forced to create a new Unified charset (or maybe it exists before computers, I don't know, but Zhiguo Yuan may tell us). This could be the reason Unified Ideograph is not included in the Japan Collection, now it's not needed since Japan Collection covers Japanese and Chinese at Time, people may going to forget about Unified ideograph and write thing like things are. The problem is that now Unified is commonly used. 4b) FPDF Japanese is used alone with a limited set of glyphs, TCPDF will permit Japanese to be used in the previous group, (along with other 16 languages). (Japanese glyphs will grow from 200 to 29,000) 4c) FPDF Chinese is used alone with a limited set of glyphs GB2312 (chinese simplified) TCPDF will enhance Chinese to a superior state: Chinese may be used in two ways, 4c1) Without Unified Ideograph. Then we can include Chinese (a rich set of Chinese) in the multilanguage group of 18 languages. 4c2) With Unified Ideograph. Then we must use the Chinese collection (this is the first time we talk about a conditional sentence in source code to do any change) to use Chinese with a full set of Chinese glyphs (simplified + traditional + others) and with English, Indonesian, Italian, Japanese and Russian. 4d) It would be possible to have all 18 webERP languages + Unified Ideograph at time, there are two ways to accomplish it: 4d1) To add Unified Ideograph to the Japan1 Collection to have a full featured Collection. (This means to create a new Collection, a new CMap and a new CIDFont and to install them in both server and client computers) 4d2) Using 2 CIDFonts in the pdf file. (This means to do a runtime text analysis to change to second font when neccesary) I must say that I didn't test the Adobe-CN1 Chinese Traditional Collection yet (but only the Adobe-GB1 Chinese Simplified Collection). Dealing with languages ... I think the meaning of "holydays" must be revised :-) Now seriously, I will test Adobe-CN1 to be sure all corners are covered by the test. > ...things are just not that easy with pdfs :-( Glad that face! Don't you think now that these are good news? Zhiguo Yuan wrote: Wish that 3.11 could switch to tcpdf. :-) Indeed, now I see it easier than I thought. But I didn't have time to look at FPDF PDF class as you mentioned some time ago, so don't trust me, things appears easier as they become familiar. > One other snag with open document format is that it does not allow for > precise positioning of text and graphics on a page, or does it?? You are totally right pdf and odt are different monsters, pdf is an Autoedition file while odt is a Word Processor one. Autoedition is about page accuracy and high quality typography, default behaviour is not to flow text to next page (Aldus PageMaker) to not missplace things on next page (think on a newspaper made with a word processor: what a nightmare). To change the font to the whole document is something neither needed nor permitted (try to do it to a pdf :-) On the other hand you can adjust types (size, kerning, hinting, etc.) and spaces, places and positions (space between lines, etc.) with an unprecedented precision. This facilitates things like to fit some text in a predetermined room with the same units used in press (picas). On the other hand, word processors are similar to typewriters, improved with thesaurus and other tools suited for writers. Word processors are better suited for writers since they don't need to adjust spaces between lines more than single, double (or 1.5) as typewriters used to do, and an Autoedition software seems very complicated for writers. Positioning in word processors use to be limited to a predefined gross grid while Autoedition software let users to define the grid precision. Both kinds of software are complementary. They both are used in press. Journalists use word processors to write their articles or columns, then texts are sended to the editorial and finally to the Autoedition. I must say that my opinion is that webERP should have both, in a similar way that now has the button csv aside pdf, a third button with odt should exist. > I am not sure if it matters that there is no browser plugin for open > document format Plugins exist for Firefox and IE in Windows. In Linux, Firefox ask to select open or save, both works. > - as long as we can download it into an external > application and have a mime type for the file of the report being > downloaded so we can open it automatically in the external program... > this is the recommended way of running pdf reports too. odt plugins for Firefox and IE in Windows may be uninstalled if desired. They are independent each other. > I still can't see a way forward with this... Hope this helps, I've been writing the whole morning from 9 to 13 :-) Phil javier AESE, S.L., Javier de Lorenzo-Cáceres. wrote: > I have been doing a lot of corrections to our CID reference page. I would > like it to be in webERP.org but it needs UTF-8. I uploaded it to > > http://www.civicom.eu/cuestore/examples.htm > > (although pdf remains generating from the same slow testing PC) > > But the most important quid is that it argues that a CMap alone doesn't > solve the trick for Chinese+Turkish (path to the solution is also argued) > and that this should not be a break, because from 18 webERP languages > (English + translations), by now, 7 are not supported by both fpdf and php > htmlspecialchars function, i.e., now there is no Turkish pdf at all (and > Czech, Hungarian, Polish, Russian, Greek and Persian are in the same > situation). > > regards, > javier > > > P.D. > (I still need to correct some things like example 2 files size cause I > changed sample texts too, and also I want to upload odts to show the > behaviour of the abscence of OOo Mime Types.) > ------------------------------------------------------------------------------ > 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 |
|
|
Re: [webERP -translation] CID update
by Javier de Lorenzo-Cáceres
::
Rate this Message:
This is great, stunning indeed, brilliant. I will try to install it to use it the same way as TCPDF, i.e., let odtPHP to read the text file from the example (or something similar) and then replaces the template tag with that text. I said in previous message that my opinion is that webERP should have both pdf and odt, in a similar way that now has the button csv aside pdf, a third button with odt should exist. Thanks a lot, javier > Hi, regarding using open document there is this library here: > > http://www.odtphp.com/ > > that allows you to create odt templates with tags in and then just > replace the tags with values in the php script. This would enable > people to create their own layouts without having to change the code. > > Thanks > Tim > > > 2009/8/22 Phil Daintree <phil@...>: >> Crickey, this is hard stuff! You have done an amazing job trying to find >> a solution for us. I am not sure I understood all of the text at >> >> > http://www.civicom.eu/cuestore/examples.htm >> >> but ... it seems that CID whilst it has the advantage of not having to >> send an embedded font with the report and clog up a slow connection, the >> CIDs are not unique and the same CID is used by a number of different >> character sets and there is overlap between character sets so you could >> get unpredictable results? I think??? >> >> So we have a dead end?? ...things are just not that easy with pdfs :-( >> >> One other snag with open document format is that it does not allow for >> precise positioning of text and graphics on a page, or does it?? >> >> I am not sure if it matters that there is no browser plugin for open >> document format - as long as we can download it into an external >> application and have a mime type for the file of the report being >> downloaded so we can open it automatically in the external program... >> this is the recommended way of running pdf reports too. >> >> I still can't see a way forward with this... >> >> Phil >> >> AESE, S.L., Javier de Lorenzo-Cáceres. wrote: >>> I have been doing a lot of corrections to our CID reference page. I >>> would like it to be in webERP.org but it needs UTF-8. I uploaded it to >>> >>> http://www.civicom.eu/cuestore/examples.htm >>> >>> (although pdf remains generating from the same slow testing PC) >>> >>> But the most important quid is that it argues that a CMap alone doesn't >>> solve the trick for Chinese+Turkish (path to the solution is also >>> argued) and that this should not be a break, because from 18 webERP >>> languages (English + translations), by now, 7 are not supported by both >>> fpdf and php htmlspecialchars function, i.e., now there is no Turkish >>> pdf at all (and Czech, Hungarian, Polish, Russian, Greek and Persian are >>> in the same situation). >>> >>> regards, >>> javier >>> >>> >>> P.D. >>> (I still need to correct some things like example 2 files size cause I >>> changed sample texts too, and also I want to upload odts to show the >>> behaviour of the abscence of OOo Mime Types.) >>> ------------------------------------------------------------------------------ >>> 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 |
|
|
Re: [webERP -translation] CID update
by Tim Schofield
::
Rate this Message:
I agree Javier, a choice is the best idea.
Tim 2009/8/22 AESE, S.L., Javier de Lorenzo-Cáceres. <info@...>: > > This is great, stunning indeed, brilliant. I will try to install it to use > it the same way as TCPDF, i.e., let odtPHP to read the text file from the > example (or something similar) and then replaces the template tag with that > text. > > I said in previous message that my opinion is that webERP should have both > pdf and odt, in a similar way that now has the button csv aside pdf, a third > button with odt should exist. > > Thanks a lot, > javier > > >> Hi, regarding using open document there is this library here: >> >> http://www.odtphp.com/ >> >> that allows you to create odt templates with tags in and then just >> replace the tags with values in the php script. This would enable >> people to create their own layouts without having to change the code. >> >> Thanks >> Tim >> >> >> 2009/8/22 Phil Daintree <phil@...>: >>> Crickey, this is hard stuff! You have done an amazing job trying to find >>> a solution for us. I am not sure I understood all of the text at >>> >>> > http://www.civicom.eu/cuestore/examples.htm >>> >>> but ... it seems that CID whilst it has the advantage of not having to >>> send an embedded font with the report and clog up a slow connection, the >>> CIDs are not unique and the same CID is used by a number of different >>> character sets and there is overlap between character sets so you could >>> get unpredictable results? I think??? >>> >>> So we have a dead end?? ...things are just not that easy with pdfs :-( >>> >>> One other snag with open document format is that it does not allow for >>> precise positioning of text and graphics on a page, or does it?? >>> >>> I am not sure if it matters that there is no browser plugin for open >>> document format - as long as we can download it into an external >>> application and have a mime type for the file of the report being >>> downloaded so we can open it automatically in the external program... >>> this is the recommended way of running pdf reports too. >>> >>> I still can't see a way forward with this... >>> >>> Phil >>> >>> AESE, S.L., Javier de Lorenzo-Cáceres. wrote: >>>> I have been doing a lot of corrections to our CID reference page. I >>>> would like it to be in webERP.org but it needs UTF-8. I uploaded it to >>>> >>>> http://www.civicom.eu/cuestore/examples.htm >>>> >>>> (although pdf remains generating from the same slow testing PC) >>>> >>>> But the most important quid is that it argues that a CMap alone doesn't >>>> solve the trick for Chinese+Turkish (path to the solution is also >>>> argued) and that this should not be a break, because from 18 webERP >>>> languages (English + translations), by now, 7 are not supported by both >>>> fpdf and php htmlspecialchars function, i.e., now there is no Turkish >>>> pdf at all (and Czech, Hungarian, Polish, Russian, Greek and Persian are >>>> in the same situation). >>>> >>>> regards, >>>> javier >>>> >>>> >>>> P.D. >>>> (I still need to correct some things like example 2 files size cause I >>>> changed sample texts too, and also I want to upload odts to show the >>>> behaviour of the abscence of OOo Mime Types.) >>>> ------------------------------------------------------------------------------ >>>> 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 |
|
|
Re: [webERP -translation] CID update
by Harald Ringehahn
::
Rate this Message:
Digitally sealed electronically signed invoices are allowed as pdf or xml, where from only pdf is "human readable", isn't it? Should such criterias come under requirement specifications?
How is this reglemented by law in which country? Harald |
| Free embeddable forum powered by Nabble | Forum Help |
