Hi,
I searched the mail list for a while and I got that if I didn't specify the
font file, it will not be embeded and Acrobat Reader will just use its own
fonts to show the characters.
I want to make some Chinese documents and I think if I don't embed any
fonts, it will be much smaller than it used to be. And there is a cool font
AdobeMingStd-Light.otf coming along with Acrobat Reader so I wish I can use
it. I converted it to ttf and then tfm files (I don't know whether it is
legal) and write the map file like:
================================
uni-AdobeMingStd-Light-00 "Adobe Ming Std" " Unicode00Encoding ReEncodeFont
"
2007/12/10, Zhichu Chen
Hi,
Hi Chen, can't you ue XeTeX or LuaTeX for your document instead of pdfTeX, it will be easier for you because you don't need tfm and map files and you need only the typescripts.
I searched the mail list for a while and I got that if I didn't specify the font file, it will not be embeded and Acrobat Reader will just use its own fonts to show the characters.
I want to make some Chinese documents and I think if I don't embed any fonts, it will be much smaller than it used to be. And there is a cool font AdobeMingStd-Light.otf coming along with Acrobat Reader so I wish I can use it. I converted it to ttf and then tfm files (I don't know whether it is legal) and write the map file like:
pdfTeX can use OpenType fonts and you don't have to convert them into TrueType format.
================================ uni-AdobeMingStd-Light-00 "Adobe Ming Std" " Unicode00Encoding ReEncodeFont "
So, any suggestions?
XeTeX or LuaTeX.
Best Regards Chen
Wolfgang
Hi, Wolfgang On Dec 11, 2007 12:05 AM, Wolfgang Schuster < schuster.wolfgang@googlemail.com> wrote:
2007/12/10, Zhichu Chen
: Hi,
Hi Chen,
can't you ue XeTeX or LuaTeX for your document instead of pdfTeX, it will be easier for you because you don't need tfm and map files and you need only the typescripts.
I don't know, but in this case, I don't want to embed fonts, I don't know how LuaTeX can do that but it runs really slow on my ancient PC, especially on the first time when it's generating font cache.
I searched the mail list for a while and I got that if I didn't specify the font file, it will not be embeded and Acrobat Reader will just use its own fonts to show the characters.
I want to make some Chinese documents and I think if I don't embed any fonts, it will be much smaller than it used to be. And there is a cool font AdobeMingStd-Light.otf coming along with Acrobat Reader so I wish I can use it. I converted it to ttf and then tfm files (I don't know whether it is legal) and write the map file like:
pdfTeX can use OpenType fonts and you don't have to convert them into TrueType format.
I convert it to ttf only because I want the tfm files, I can't find there's a tool that can to otf2tfm. And then I deleted the ttf and the otf fonts because I don't want to embed them so I don't need them any more.
================================ uni-AdobeMingStd-Light-00 "Adobe Ming Std" " Unicode00Encoding ReEncodeFont "
So, any suggestions?
XeTeX or LuaTeX.
Best Regards Chen
Wolfgang
___________________________________________________________________________________ If your question is of interest to others as well, please add an entry to the Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://tex.aanhet.net archive : https://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net
___________________________________________________________________________________
Anyway, thank you for paying attention to my stupid and almost useless topic. -- Best Regards Chen ---------------------------------------------------------------- Zhi-chu Chen | Shanghai Synchrotron Radiation Facility No. 2019 | Jialuo Rd. | Jiading | Shanghai | P.R. China tel: 086 21 5955 3405 | zhichu.chen.googlepages.com | www.sinap.ac.cn ----------------------------------------------------------------
I don't know, but in this case, I don't want to embed fonts, I don't know how LuaTeX can do that
LuaTeX knows how to not embed fonts if you ask it not to, but I'm not sure how this is handled on the ConTeXt level.
but it runs really slow on my ancient PC, especially on the first time when it's generating font cache.
That's true, it needs a lot of memory (so most of the time is spent swapping, I guess). As I've found out, Mark IV is slightly faster on a 450 MHz Sparc processor with 1GB memory than on a 2GHz Intel Dual Core with 512MB memory ;-) But is it still too slow after the first pass?
I convert it to ttf only because I want the tfm files, I can't find there's a tool that can to otf2tfm.
Actually there is one that comes with the lcdf typetools. It even ships with TeX Live. Arthur
Arthur Reutenauer wrote:
I don't know, but in this case, I don't want to embed fonts, I don't know how LuaTeX can do that
LuaTeX knows how to not embed fonts if you ask it not to, but I'm not sure how this is handled on the ConTeXt level.
but it runs really slow on my ancient PC, especially on the first time when it's generating font cache.
That's true, it needs a lot of memory (so most of the time is spent swapping, I guess). As I've found out, Mark IV is slightly faster on a 450 MHz Sparc processor with 1GB memory than on a 2GHz Intel Dual Core with 512MB memory ;-)
This is especially true if you use large fonts like the AdobeMingStd. It should slowly be getting better over time, Hans and I hope. We try to optimize for memory use as well as directly for speed, because less memory is often faster also. However, premature size optimizations tend to cause problems later on, and therefore progress is slow. Best wishes, Taco
2007/12/10, Taco Hoekwater
Arthur Reutenauer wrote:
I don't know, but in this case, I don't want to embed fonts, I don't know how LuaTeX can do that
LuaTeX knows how to not embed fonts if you ask it not to, but I'm not sure how this is handled on the ConTeXt level.
but it runs really slow on my ancient PC, especially on the first time when it's generating font cache.
That's true, it needs a lot of memory (so most of the time is spent swapping, I guess). As I've found out, Mark IV is slightly faster on a 450 MHz Sparc processor with 1GB memory than on a 2GHz Intel Dual Core with 512MB memory ;-)
This is especially true if you use large fonts like the AdobeMingStd. It should slowly be getting better over time, Hans and I hope. We try to optimize for memory use as well as directly for speed, because less memory is often faster also. However, premature size optimizations tend to cause problems later on, and therefore progress is slow.
Slow is no word for the speed with CJK, I have a document with Adobe Kozuka Minchi and Gothic and run takes up to 3 to 4 minutes. The same document needs with XeTeX about half a minute and using the same fonts in plain TeX took only a few seconds. This is really something LuaTeX need to be faster, but it is always faster than using the cwTeX in truetype format with pdfTeX ;-) Wolfgang
Wolfgang Schuster wrote:
Slow is no word for the speed with CJK, I have a document with Adobe Kozuka Minchi and Gothic and run takes up to 3 to 4 minutes.
The same document needs with XeTeX about half a minute and using the same fonts in plain TeX took only a few seconds.
This is really something LuaTeX need to be faster, but it is always faster than using the cwTeX in truetype format with pdfTeX ;-)
it all depends on what's done with the font ... -- we can only locate a bottleneck when we have the font and a test file -- when you're low on memory, the garbage collector of lua becomes a problem -- dynamic features are faster (less loading) 3-4 minutes ... we use mk.tex as test doc, and that one loads cjk as well as zapfino and arab ... runtime on my machine is 15-20 sec, depending on the console used an din bachmode we go under 15 seconds (140 page document) so, what kind of machine do you run luatex on? Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
Thanks guys, Actually, I'm running Debian on a very small partition, so I don't have much spaces for the font cache. So every time I wanna download a big patch like openoffice, KDE upgrade or something else, the cache is the first thing I delete. I don't think it makes much sense so I just make luatex rest for a while until I got a chance to format my entire hard disk. And, for my case, I don't think luatex will show its advantage here, because I don't need it to treat the opentype fonts. Chinese characters are almost the same size, so I think we can even make a universal .tfm files which could match all CJK fonts. So technically, I don't need the AdobeMingStd-Light.otf to get these tfm files. Anyway, what I'm wondering is how to design the map file. What should I write on the basename column? I read about the pdftex manual but can't get much help. I've tried some other fonts, but only SimSun works, it's pretty weird. -- Best Regards Chen ---------------------------------------------------------------- Zhi-chu Chen | Shanghai Synchrotron Radiation Facility No. 2019 | Jialuo Rd. | Jiading | Shanghai | P.R. China tel: 086 21 5955 3405 | zhichu.chen.googlepages.com | www.sinap.ac.cn ----------------------------------------------------------------
2007/12/10, Hans Hagen
Wolfgang Schuster wrote:
Slow is no word for the speed with CJK, I have a document with Adobe Kozuka Minchi and Gothic and run takes up to 3 to 4 minutes.
The same document needs with XeTeX about half a minute and using the same fonts in plain TeX took only a few seconds.
This is really something LuaTeX need to be faster, but it is always faster than using the cwTeX in truetype format with pdfTeX ;-)
it all depends on what's done with the font ...
-- we can only locate a bottleneck when we have the font and a test file -- when you're low on memory, the garbage collector of lua becomes a problem -- dynamic features are faster (less loading)
3-4 minutes ... we use mk.tex as test doc, and that one loads cjk as well as zapfino and arab ... runtime on my machine is 15-20 sec, depending on the console used an din bachmode we go under 15 seconds (140 page document)
so, what kind of machine do you run luatex on?
Hans
I run LuaTeX on a songle core pentium M with 1.7 GHz and 512 MB ram, I made now a smell test file and the problem the speed with this file is not so bad, the compile time increases with every \switchtobodyfont in my document and not every of them can be replaced. Wolfgang
Wolfgang Schuster wrote:
2007/12/10, Hans Hagen
: Wolfgang Schuster wrote:
Slow is no word for the speed with CJK, I have a document with Adobe Kozuka Minchi and Gothic and run takes up to 3 to 4 minutes.
The same document needs with XeTeX about half a minute and using the same fonts in plain TeX took only a few seconds.
This is really something LuaTeX need to be faster, but it is always faster than using the cwTeX in truetype format with pdfTeX ;-) it all depends on what's done with the font ...
-- we can only locate a bottleneck when we have the font and a test file -- when you're low on memory, the garbage collector of lua becomes a problem -- dynamic features are faster (less loading)
3-4 minutes ... we use mk.tex as test doc, and that one loads cjk as well as zapfino and arab ... runtime on my machine is 15-20 sec, depending on the console used an din bachmode we go under 15 seconds (140 page document)
so, what kind of machine do you run luatex on?
Hans
I run LuaTeX on a songle core pentium M with 1.7 GHz and 512 MB ram,
it helps to have a gig or more
I made now a smell test file and the problem the speed with this file is not so bad, the compile time increases with every \switchtobodyfont in my document and not every of them can be replaced.
eventually you can share most instances and load only once (i.e. normally only 4 fonts need to be loaded + some math) Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
Wolfgang Schuster wrote:
I run LuaTeX on a songle core pentium M with 1.7 GHz and 512 MB ram, I made now a smell test file and the problem the speed with this file is not so bad, the compile time increases with every \switchtobodyfont in my document and not every of them can be replaced.
It seems to generate pages at an acceptable rate, it is just the font loading that is slow. Do you agree? Best wishes, Taco
2007/12/11, Taco Hoekwater
Wolfgang Schuster wrote:
I run LuaTeX on a songle core pentium M with 1.7 GHz and 512 MB ram, I made now a smell test file and the problem the speed with this file is not so bad, the compile time increases with every \switchtobodyfont in my document and not every of them can be replaced.
It seems to generate pages at an acceptable rate, it is just the font loading that is slow. Do you agree?
Best wishes, Taco
Yes, only the font loading takes very long, the document processing is a little bit slower than normal but it is ok. Only the font embedding or whatever happens at the end of the documents takes more time than normal but this could be related to the font size. Wolfgang
Wolfgang Schuster wrote:
2007/12/11, Taco Hoekwater
: Wolfgang Schuster wrote:
I run LuaTeX on a songle core pentium M with 1.7 GHz and 512 MB ram, I made now a smell test file and the problem the speed with this file is not so bad, the compile time increases with every \switchtobodyfont in my document and not every of them can be replaced. It seems to generate pages at an acceptable rate, it is just the font loading that is slow. Do you agree?
Best wishes, Taco
Yes, only the font loading takes very long, the document processing is a little bit slower than normal but it is ok. Only the font embedding or whatever happens at the end of the documents takes more time than normal but this could be related to the font size.
most probably a memory problem btw, are you sure that you copied luatex.exe to texluac.exe? otherwise you don't get compiled font tables (if not, then copy and delete the cache) hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
2007/12/11, Hans Hagen
Wolfgang Schuster wrote:
2007/12/11, Taco Hoekwater
: Wolfgang Schuster wrote:
I run LuaTeX on a songle core pentium M with 1.7 GHz and 512 MB ram, I made now a smell test file and the problem the speed with this file is not so bad, the compile time increases with every \switchtobodyfont in my document and not every of them can be replaced. It seems to generate pages at an acceptable rate, it is just the font loading that is slow. Do you agree?
Best wishes, Taco
Yes, only the font loading takes very long, the document processing is a little bit slower than normal but it is ok. Only the font embedding or whatever happens at the end of the documents takes more time than normal but this could be related to the font size.
most probably a memory problem
btw, are you sure that you copied luatex.exe to texluac.exe? otherwise you don't get compiled font tables (if not, then copy and delete the cache)
Yes I did this and I changed my font settings for the title page to \definedfont in my document takes now 80 seconds for a single run but it spends most of the time for font loading. But you can beat the process time of plain TeX which can be used in simple documents where you can reduce the time with a few tricks. My process time for vocabulary cards from a xml file is below 1 second and I have more than 4.000 pages ;-) Doing the same thing woth ConTeXt's old xml interface and XeTeX takes 30 seconds and I won't talk about mkiv. Wolfgang
Wolfgang Schuster wrote:
Yes I did this and I changed my font settings for the title page to \definedfont in my document takes now 80 seconds for a single run but it spends most of the time for font loading.
much overhead is related to things like setting up math, synchronizing encodings, mappings, (and hz, protruding if enabled) .. keep in mind that we're talking of font systems, not one font
But you can beat the process time of plain TeX which can be used in simple documents where you can reduce the time with a few tricks. My process time for vocabulary cards from a xml file is below 1 second and I have more than 4.000 pages ;-) Doing the same thing woth ConTeXt's old xml interface and XeTeX takes 30 seconds and I won't talk about mkiv.
it all depends on what functionality is needed (take pagebody construction, which in plain is hardly present, backgrounds, color, etc etc) and in the case of xml it also depends on what 'defineXML' commands are used; things like namespaces (fallbacks), attributes etc etc ... many things play a role and i'm pretty sure that the critical parts of context are quite optimized; for sure many (simple) docs can be processed using plain tex but as soon as you need a bit more ... (btw, xml in mkiv is quite different, since it operates on trees) Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
2007/12/12, Hans Hagen
Wolfgang Schuster wrote:
Yes I did this and I changed my font settings for the title page to \definedfont in my document takes now 80 seconds for a single run but it spends most of the time for font loading.
much overhead is related to things like setting up math, synchronizing encodings, mappings, (and hz, protruding if enabled) .. keep in mind that we're talking of font systems, not one font
loading the fonts is sometimes the slowest thing in a document.
But you can beat the process time of plain TeX which can be used in simple documents where you can reduce the time with a few tricks. My process time for vocabulary cards from a xml file is below 1 second and I have more than 4.000 pages ;-) Doing the same thing woth ConTeXt's old xml interface and XeTeX takes 30 seconds and I won't talk about mkiv.
it all depends on what functionality is needed (take pagebody construction, which in plain is hardly present, backgrounds, color, etc etc) and in the case of xml it also depends on what 'defineXML' commands are used; things like namespaces (fallbacks), attributes etc etc ... many things play a role and i'm pretty sure that the critical parts of context are quite optimized; for sure many (simple) docs can be processed using plain tex but as soon as you need a bit more ...
I wanted to show only it is sometimes to enough to use a low level system and you don't need such a complex system like ConTeXt. My document was also optimized to speed and I work without page numbering (first step) and dropped in a second step the output routine, I use \shipout to place the data from the file and write the information to the file. The strong point from my ConTeXt solution is to have better control over the layout, my plain solution use hboxes and vboxes where I use layers in ConTeXt and this is easier. My simple XML handler is also very limited and has only support for environments and pickups but nothing else.
(btw, xml in mkiv is quite different, since it operates on trees)
It is possible to use the old and new method in some documents in the same way but I prefer the new method because I can now use xml files to store information without the need to store the data before the run in TeX macros. Wolfgang
Wolfgang Schuster wrote:
It is possible to use the old and new method in some documents in the same way but I prefer the new method because I can now use xml files to store information without the need to store the data before the run in TeX macros.
i will not remove the old method if only because there is code in context that uses it (it will take some time to migrate that to mkiv files) Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
2007/12/13, Hans Hagen
Wolfgang Schuster wrote:
It is possible to use the old and new method in some documents in the same way but I prefer the new method because I can now use xml files to store information without the need to store the data before the run in TeX macros.
i will not remove the old method if only because there is code in context that uses it (it will take some time to migrate that to mkiv files)
I never want the old method to vanisch because mkii (and mkiii) need it there is often no difference in the code to format the output, the only difference is I have to store the the information in mkii before I use them wheras I can no live without this but thats only a few lines in my code and the rest is the same. Wolfgang
Hi guys, Maybe this post has gone too far, and I've tried a bunch of methods to get my map work. Anyway, I can't. And there's something I must say, why pdftex must embed the whole otf file? It's about 15M for my only-one-character test file and about 20M for my another only-two-characters test file, besides, embedding otf files are so so slow. I don't think I'm ready for otf yet. -- Best Regards Chen ---------------------------------------------------------------- Zhi-chu Chen | Shanghai Synchrotron Radiation Facility No. 2019 | Jialuo Rd. | Jiading | Shanghai | P.R. China tel: 086 21 5955 3405 | zhichu.chen.googlepages.com | www.sinap.ac.cn ----------------------------------------------------------------
2007/12/13, Zhichu Chen
Hi guys,
Maybe this post has gone too far, and I've tried a bunch of methods to get my map work. Anyway, I can't. And there's something I must say, why pdftex must embed the whole otf file? It's about 15M for my only-one-character test file and about 20M for my another only-two-characters test file, besides, embedding otf files are so so slow. I don't think I'm ready for otf yet.
I tried the Song font from Adobe a few days ago with XeTeX and a older chinese example text from you and the file size with 37 pages of output was a little bit over 1 MB, the same result with luaTeX but I got more pages. Wolfgang
Hi Wolfgang,
On Dec 13, 2007 7:17 PM, Wolfgang Schuster
Hi guys,
Maybe this post has gone too far, and I've tried a bunch of methods to get my map work. Anyway, I can't. And there's something I must say, why
2007/12/13, Zhichu Chen
: pdftex must embed the whole otf file? It's about 15M for my only-one-character test file and about 20M for my another only-two-characters test file, besides, embedding otf files are so so slow. I don't think I'm ready for otf yet.
I tried the Song font from Adobe a few days ago with XeTeX and a older chinese example text from you and the file size with 37 pages of output was a little bit over 1 MB, the same result with luaTeX but I got more pages.
Then XeTeX can treat otf fonts correctly? I never tried that. I convert the otf file into multiple type1 fonts (which compiles much more faster on my PC) and I got 1.7M with 60 pages with pdftex embed the subsets. And I got 440.9K with the same document and the same tfm files except I specify Adobe Reader to use SimSun and not embed any fonts. I like the later.
Wolfgang
___________________________________________________________________________________ If your question is of interest to others as well, please add an entry to the Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://tex.aanhet.net archive : https://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net
___________________________________________________________________________________
-- Best Regards Chen ---------------------------------------------------------------- Zhi-chu Chen | Shanghai Synchrotron Radiation Facility No. 2019 | Jialuo Rd. | Jiading | Shanghai | P.R. China tel: 086 21 5955 3405 | zhichu.chen.googlepages.com | www.sinap.ac.cn ----------------------------------------------------------------
Zhichu Chen wrote:
Hi Wolfgang,
On Dec 13, 2007 7:17 PM, Wolfgang Schuster
wrote: Hi guys,
Maybe this post has gone too far, and I've tried a bunch of methods to get my map work. Anyway, I can't. And there's something I must say, why
must embed the whole otf file? It's about 15M for my only-one-character test file and about 20M for my another only-two-characters test file, besides, embedding otf files are so so slow. I don't think I'm ready for otf yet. I tried the Song font from Adobe a few days ago with XeTeX and a older chinese example text from you and the file size with 37 pages of output was a little bit over 1 MB, the same result with luaTeX but I got more
2007/12/13, Zhichu Chen
: pdftex pages. Then XeTeX can treat otf fonts correctly? I never tried that. I convert the otf file into multiple type1 fonts (which compiles much more faster on my PC) and I got 1.7M with 60 pages with pdftex embed the subsets. And I got 440.9K with the same document and the same tfm files except I specify Adobe Reader to use SimSun and not embed any fonts. I like the later.
xetex just pipes data into dvipdfmx, and dvipdfmx can subset (this was accomplished by Chof, who lives in Korea and uses huge fonts) Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
2007/12/14, Hans Hagen
Zhichu Chen wrote:
Hi Wolfgang,
On Dec 13, 2007 7:17 PM, Wolfgang Schuster
wrote: Hi guys,
Maybe this post has gone too far, and I've tried a bunch of methods to get my map work. Anyway, I can't. And there's something I must say, why
must embed the whole otf file? It's about 15M for my only-one-character test file and about 20M for my another only-two-characters test file, besides, embedding otf files are so so slow. I don't think I'm ready for otf yet. I tried the Song font from Adobe a few days ago with XeTeX and a older chinese example text from you and the file size with 37 pages of output was a little bit over 1 MB, the same result with luaTeX but I got more
2007/12/13, Zhichu Chen
: pdftex pages. Then XeTeX can treat otf fonts correctly? I never tried that. I convert the otf file into multiple type1 fonts (which compiles much more faster on my PC) and I got 1.7M with 60 pages with pdftex embed the subsets. And I got 440.9K with the same document and the same tfm files except I specify Adobe Reader to use SimSun and not embed any fonts. I like the later.
xetex just pipes data into dvipdfmx, and dvipdfmx can subset (this was accomplished by Chof, who lives in Korea and uses huge fonts)
But you don't have to care about this normally because this is done automatic, it is harder to prevent this ConTeXt and produce only xdv files. The file size with XeTeX should be the same as in the pdfTeX way but I found no way to prevent xdvipdfmx to embedd the fonts, I know there is a "-e" flag but I don't if this should only lead to embedd the complete font or to disable font embedding but I can't test this because my xdvipdfmx has no "-e" flag. Wolfgang
Hi Wolfgang,
On Dec 14, 2007 6:24 PM, Wolfgang Schuster
Zhichu Chen wrote:
Hi Wolfgang,
On Dec 13, 2007 7:17 PM, Wolfgang Schuster < schuster.wolfgang@googlemail.com> wrote:
Hi guys,
Maybe this post has gone too far, and I've tried a bunch of methods to get my map work. Anyway, I can't. And there's something I must say, why
2007/12/13, Zhichu Chen
: pdftex must embed the whole otf file? It's about 15M for my only-one-character test file and about 20M for my another only-two-characters test file, besides, embedding otf files are so so slow. I don't think I'm ready for otf yet. I tried the Song font from Adobe a few days ago with XeTeX and a
2007/12/14, Hans Hagen
: older chinese example text from you and the file size with 37 pages of output was a little bit over 1 MB, the same result with luaTeX but I got more pages.
Then XeTeX can treat otf fonts correctly? I never tried that. I convert the otf file into multiple type1 fonts (which compiles much more faster on my PC) and I got 1.7M with 60 pages with pdftex embed the subsets. And I got 440.9K with the same document and the same tfm files except I specify Adobe Reader to use SimSun and not embed any fonts. I like the later.
xetex just pipes data into dvipdfmx, and dvipdfmx can subset (this was accomplished by Chof, who lives in Korea and uses huge fonts)
But you don't have to care about this normally because this is done automatic, it is harder to prevent this ConTeXt and produce only xdv files.
The file size with XeTeX should be the same as in the pdfTeX way but I found no way to prevent xdvipdfmx to embedd the fonts, I know there is a "-e" flag but I don't if this should only lead to embedd the complete font or to disable font embedding but I can't test this because my xdvipdfmx has no "-e" flag.
No offense but xdvipdfmx has some problem with the graphics. I'm kind of one of the managers of the Chinese TeX Society and we have a forum called CTeX forum, and there're a lot of posts complaining that xdvipdfmx will cut part of their graphics. For instance, if they draw a picture with metapost, xdvipdfmx will only show the first quadrant of it. I guess it's confused about the boundingbox and the accordinate.
Wolfgang
___________________________________________________________________________________ If your question is of interest to others as well, please add an entry to the Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://tex.aanhet.net archive : https://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net
___________________________________________________________________________________
-- Best Regards Chen ---------------------------------------------------------------- Zhi-chu Chen | Shanghai Synchrotron Radiation Facility No. 2019 | Jialuo Rd. | Jiading | Shanghai | P.R. China tel: 086 21 5955 3405 | zhichu.chen.googlepages.com | www.sinap.ac.cn ----------------------------------------------------------------
Zhichu Chen wrote:
No offense but xdvipdfmx has some problem with the graphics. I'm kind of one of the managers of the Chinese TeX Society and we have a forum called CTeX forum, and there're a lot of posts complaining that xdvipdfmx will cut part of their graphics. For instance, if they draw a picture with metapost, xdvipdfmx will only show the first quadrant of it. I guess it's confused about the boundingbox and the accordinate.
i suppose that this concerns the native dvipdfmx mp inclusion (which is experimental), inclusion using supp-pdf should work ok in dvipdfmx Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
Zhichu Chen wrote:
Hi guys,
Maybe this post has gone too far, and I've tried a bunch of methods to get my map work. Anyway, I can't. And there's something I must say, why pdftex must embed the whole otf file? It's about 15M for my only-one-character test file and about 20M for my another only-two-characters test file, besides, embedding otf files are so so slow. I don't think I'm ready for otf yet.
afaik pdftex does not do subsetting of cid fonts, but luatex does Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
Thanks Hans. Do you have any comments about how to now embed the standard
Adobe CJK fonts?
On Dec 13, 2007 8:25 PM, Hans Hagen
Hi guys,
Maybe this post has gone too far, and I've tried a bunch of methods to get my map work. Anyway, I can't. And there's something I must say, why
Zhichu Chen wrote: pdftex
must embed the whole otf file? It's about 15M for my only-one-character test file and about 20M for my another only-two-characters test file, besides, embedding otf files are so so slow. I don't think I'm ready for otf yet.
afaik pdftex does not do subsetting of cid fonts, but luatex does
Hans
----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
___________________________________________________________________________________ If your question is of interest to others as well, please add an entry to the Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://tex.aanhet.net archive : https://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net
___________________________________________________________________________________
-- Best Regards Chen ---------------------------------------------------------------- Zhi-chu Chen | Shanghai Synchrotron Radiation Facility No. 2019 | Jialuo Rd. | Jiading | Shanghai | P.R. China tel: 086 21 5955 3405 | zhichu.chen.googlepages.com | www.sinap.ac.cn ----------------------------------------------------------------
Zhichu Chen wrote:
Thanks Hans. Do you have any comments about how to now embed the standard Adobe CJK fonts?
you can split up the ttf file in smaller pfb files matching the tfm's Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
Sorry Hans, I mean not embed, there's a typo in my last post.
I've broken the otf file into multiple type 1 fonts before, and it compiles
very fast comparing to ttf or otf. But I don't know whether it is legal to
embed those pfb files.
On Dec 14, 2007 4:03 PM, Hans Hagen
Zhichu Chen wrote:
Thanks Hans. Do you have any comments about how to now embed the standard Adobe CJK fonts?
you can split up the ttf file in smaller pfb files matching the tfm's
Hans
----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
___________________________________________________________________________________ If your question is of interest to others as well, please add an entry to the Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://tex.aanhet.net archive : https://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net
___________________________________________________________________________________
-- Best Regards Chen ---------------------------------------------------------------- Zhi-chu Chen | Shanghai Synchrotron Radiation Facility No. 2019 | Jialuo Rd. | Jiading | Shanghai | P.R. China tel: 086 21 5955 3405 | zhichu.chen.googlepages.com | www.sinap.ac.cn ----------------------------------------------------------------
2007/12/17, Zhichu Chen
Sorry Hans, I mean not embed, there's a typo in my last post.
I've broken the otf file into multiple type 1 fonts before, and it compiles very fast comparing to ttf or otf. But I don't know whether it is legal to embed those pfb files.
LuaTeX is now also very fast to process CJK documents, my Chinese example file compiles in afew seconds, it takes only a long time ti save the font information at the first to use the font but it is no problem in the later runs. Wolfgang
Hello Zhichu and all,
Thanks Hans. Do you have any comments about how to now embed the standard Adobe CJK fonts?
I made experiments with pdfTeX in order to produce a file with Chinese text without embedding the font. It actually works---with minor inconvenients---and I attach a small example file which uses AdobeMingStd-Light. It should of course be possible to adapt it for the Adobe font for Simplified Chinese (AdobeSongStd-Light), as well as for Japanese or Korean. Here is how you should use it: - Produce the TFM files for the subfonts of AdobeMingStd-Light. You should call them uni-adobe-ming-XX.tfm where XX is the number of the Unicode row (the range from U+XX00 to U+XXFF); I guess you know how to do that. - Find a way to deactivate mktexpk somehow: the point is that my macros emulate the subfonts in PDF directly, but pdfTeX doesn't know that and wants to find the glyphs somewhere. Since they're not present anywhere, he calls mktexpk as a last resort, but that fails as well and it's only a waste of time. So you need to simply deactivate mktexpk (I hope it's not an inconvenience for you and you don't rely on PK generation otherwise). When running on a shell on Unix I can say "export MKTEXPK=echo" (and the call to mktexpk is replaced by a simple echo). There may be options in mktex.cnf or mktex.opt which would enable you to set things platform-independently, but I couldn't find anything useful. On the other hand, if you can't do that, it also works but you waste some time in the process. The central idea of my macros is to use CIDFont's, a concept introduced by Adobe for its CJKV fonts, as I'm sure you know. The point is that all of the standard Adobe CJKV fonts are CIDFont's and use a special kind of encoding called CID encoding, which is quite distinct from encoding based on glyph names as used by Type 1 fonts. I think this is why your attempts by using .enc files didn't work; I strongly suspect it's not possible at all to use .enc files with CIDFont's, and you have to use the equivalent concept for CID encoding, that is CMap. This is what I have done here, by embedding the appropriate CMap for each subfont. Since it's an example file, I only wrote the CMap's for the Unicode rows U+51XX, U+66XX and U+67XX, so you would have to enhance it if you want to use the other Chinese characters. It's easy to do, but it's a further inconvenience of this approach, since it means you have to embed a CMap which weigh 2 to 5 KB for each Unicode row (that is, up to 256 characters). I hope it works for you. I also attach the output by pdfTeX on my machine. Obviously this is somewhat cumbersome in pdfTeX and would be much easier to do with LuaTeX (where you don't need subfonts at all), but I didn't look into that. XeTeX wouldn't work the same way since you can't write PDF objects directly the way I've done it. Arthur
Arthur Reutenauer wrote:
Unix I can say "export MKTEXPK=echo" (and the call to mktexpk is
no problem to disable that one in texexec, unless of course someone is depending on it; btw, setting MKTEXTEX=0 in texmf.cnf should also disable it ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
2007/12/29, Arthur Reutenauer
each subfont. Since it's an example file, I only wrote the CMap's for the Unicode rows U+51XX, U+66XX and U+67XX, so you would have to enhance it if you want to use the other Chinese characters. It's easy to do, but it's a further inconvenience of this approach, since it means you have to embed a CMap which weigh 2 to 5 KB for each Unicode row (that is, up to 256 characters).
Amazing work. I wonder at the /Flags 12, though: Symbolic Script. %-) Although I doubt that any value of /Flags entry will work in your case, is the 12 just coincidence or does it have meaning? Best Martin
Amazing work.
Thanks :-)
I wonder at the /Flags 12, though: Symbolic Script. %-)
I based myself on the PDF reference, that says "Symbolic" means "contains glyphs outside the Adobe standard Latin character set" (page 458 of http://www.adobe.com/devnet/acrobat/pdfs/pdf_reference_1-7.pdf -- although it's formally contradicted by the pdfTeX manual ;-) This is definitely the case here, so I set that on purpose. The bit 2 is set on purpose too, since Ming / Song style is more or less a Serif sort of font. But now I realize I should have set Flags to 6 = 2^(2-1) + 2^(3-1) instead of 12 = 2^2 + 2^3. Anyway, as you say, the font flags are probably unusable here. Happy New Year everyone! Arthur
2007/12/10, Zhichu Chen
Hi, Wolfgang
On Dec 11, 2007 12:05 AM, Wolfgang Schuster
wrote: 2007/12/10, Zhichu Chen
: Hi,
Hi Chen,
can't you ue XeTeX or LuaTeX for your document instead of pdfTeX, it will be easier for you because you don't need tfm and map files and you need only the typescripts.
I don't know, but in this case, I don't want to embed fonts, I don't know how LuaTeX can do that but it runs really slow on my ancient PC, especially on the first time when it's generating font cache.
This is funny because the following comment is from font-otf.lua -- han (chinese) (unfinished) -- this info eventually will go into char-def -- list by Zhichu Chen list of left and right delimiters for chinese You should try XeTeX for the moment and not LuaTeX, the first is as fast as pdfTeX while the second is currently not really usable for CJK.
I searched the mail list for a while and I got that if I didn't specify the font file, it will not be embeded and Acrobat Reader will just use its own fonts to show the characters.
I want to make some Chinese documents and I think if I don't embed any fonts, it will be much smaller than it used to be. And there is a cool font AdobeMingStd-Light.otf coming along with Acrobat Reader so I wish I can use it. I converted it to ttf and then tfm files (I don't know whether it is legal) and write the map file like:
pdfTeX can use OpenType fonts and you don't have to convert them into TrueType format.
I convert it to ttf only because I want the tfm files, I can't find there's a tool that can to otf2tfm. And then I deleted the ttf and the otf fonts because I don't want to embed them so I don't need them any more.
A opentype to tfm converter is included in the LCDF Typetools http://www.lcdf.org/type/index.html, I used for a short time in the past but use now the modern backends instead of pdfTeX.
uni-AdobeMingStd-Light-00 "Adobe Ming Std" " Unicode00Encoding ReEncodeFont "
So, any suggestions?
XeTeX or LuaTeX.
Anyway, thank you for paying attention to my stupid and almost useless topic.
Don't say this, font questions are never useless. Wolfgang
On Dec 10, 2007 4:58 PM, Zhichu Chen wrote:
And the second column is for the PS name of the font. I really don't know how to write it because it has spaces in it, and when I replaced it with another PS name that has no spaces or other special characters in it, say SimSun as a common Simplified Chinese font in Windows, it worked fine.
So, any suggestions?
You can get the PS name of some font with otfinfo: -p, --postscript-name Print each font's PostScript name. For example: MinionPro-SemiboldItCapt So: otfinfo -p AdobeMingStd-Light.otf which returns AdobeMingStd-Light here. But I would be a bit surprised if you would manage to make it work that way. Mojca
On Dec 11, 2007 12:37 AM, Mojca Miklavec
On Dec 10, 2007 4:58 PM, Zhichu Chen wrote:
And the second column is for the PS name of the font. I really don't know
how to
write it because it has spaces in it, and when I replaced it with another PS name that has no spaces or other special characters in it, say SimSun as a common Simplified Chinese font in Windows, it worked fine.
So, any suggestions?
You can get the PS name of some font with otfinfo: -p, --postscript-name Print each font's PostScript name. For example: MinionPro-SemiboldItCapt So: otfinfo -p AdobeMingStd-Light.otf which returns AdobeMingStd-Light here.
But I would be a bit surprised if you would manage to make it work that way.
Yes, it doesn't work :( I have seen some pdf files that Acrobat Reader can automatically download fonts for them. I had thought that the reader may have some kind of font list so that if some unusual (non-base) fonts are invoked, it will just down them from the Adobe ftp. I guess I was wrong. I think I should read more about those Adobe specials.
Mojca
___________________________________________________________________________________ If your question is of interest to others as well, please add an entry to the Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://tex.aanhet.net archive : https://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net
___________________________________________________________________________________
-- Best Regards Chen ---------------------------------------------------------------- Zhi-chu Chen | Shanghai Synchrotron Radiation Facility No. 2019 | Jialuo Rd. | Jiading | Shanghai | P.R. China tel: 086 21 5955 3405 | zhichu.chen.googlepages.com | www.sinap.ac.cn ----------------------------------------------------------------
2007/12/10, Mojca Miklavec
On Dec 10, 2007 4:58 PM, Zhichu Chen wrote:
And the second column is for the PS name of the font. I really don't know how to write it because it has spaces in it, and when I replaced it with another PS name that has no spaces or other special characters in it, say SimSun as a common Simplified Chinese font in Windows, it worked fine.
So, any suggestions?
You can get the PS name of some font with otfinfo: -p, --postscript-name Print each font's PostScript name. For example: MinionPro-SemiboldItCapt So: otfinfo -p AdobeMingStd-Light.otf which returns AdobeMingStd-Light here.
But I would be a bit surprised if you would manage to make it work that way.
Mojca
It is also possible to show all font names and features with extra programm in windows. You can click with the right mouse button on the font and it shows you the font names, opentype features ... I'm not if the following link is correct but it should do the same work as otfinfo (which is include in the LCDF typetools, metioned in another message) http://www.microsoft.com/typography/TrueTypeProperty21.mspx Wolfgang
participants (7)
-
Arthur Reutenauer
-
Hans Hagen
-
Martin Schröder
-
Mojca Miklavec
-
Taco Hoekwater
-
Wolfgang Schuster
-
Zhichu Chen