Re: [NTG-context] font-syn.lua error
Alan BRASLAU wrote: Maybe unrelated, but maybe a luatex error as well: transparency seems to work correctly when viewed with okular (same library as evince) but not when view with acroread, (including the windows version). What is 'not'? If you means that the rest of the page looks crappy, that is known Acrobat behavior. If you want all pages to look the same (crappy) in AR, use \TransparancyHack. If there is no transparancy at all, then there could be a problem within mkiv or luatex. Best wishes, Taco ___ 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 : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___
Re: [NTG-context] font-syn.lua error
Thomas A. Schmitz wrote: On Nov 25, 2009, at 8:15 AM, luigi scarso wrote: 1. In evince under linux, the file looked fine, no problems were apparent. what about xpdf and ghostscript? Can you also try with mupdf ? mupdf quite often crashes on completely valid pdf documents, effectively making it useless in practice. What's worse: those bugs are hard to fix because some really bad implementation decisions were made. Best wishes, Taco ___ 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 : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___
Re: [NTG-context] font-syn.lua error
On Wed, Nov 25, 2009 at 8:48 AM, Thomas A. Schmitz thomas.schm...@uni-bonn.de wrote: On Nov 25, 2009, at 8:15 AM, luigi scarso wrote: 1. In evince under linux, the file looked fine, no problems were apparent. what about xpdf and ghostscript? Can you also try with mupdf ? That wasn't the point, I was not trying to give a comparative table of pdf-viewers. luatex was buggy, but some viewers displayed the pdf nonetheless. Doesn't make sense to test a dozen viewers because next time around, the subset which does or does not work may be totally different. Not dozen, only 2~3 but code independent .My choices are 1) xpdf (same codebase of luatex) 2)acroread (the most important viewer for pdf ) 3) ghostscript (also used by context ) They are all used / important for TeX community and printing house. mupdf comes from ghostscript team , it's quick but young, it comes with some interesting cmdline tools . Until now I was not able to use it as viewer in everyday use, so I don't know if it's good or not for checking pdf made by luatex I believe that Taco knows mupdf better than me. -- luigi ___ 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 : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___
Re: [NTG-context] font-syn.lua error
ah I've seen it just now On Wed, Nov 25, 2009 at 9:40 AM, Taco Hoekwater t...@elvenkind.com wrote: mupdf quite often crashes on completely valid pdf documents, effectively making it useless in practice. hm bad news, What's worse: those bugs are hard to fix because some really bad implementation decisions were made. What are these decisions ? -- luigi ___ 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 : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___
Re: [NTG-context] font-syn.lua error
luigi scarso wrote: ah I've seen it just now On Wed, Nov 25, 2009 at 9:40 AM, Taco Hoekwater t...@elvenkind.com wrote: mupdf quite often crashes on completely valid pdf documents, effectively making it useless in practice. hm bad news, What's worse: those bugs are hard to fix because some really bad implementation decisions were made. What are these decisions ? Using the C stack for recursion is the main problem. Pdfs with a large number of objects (annots) are likely to exhaust the stack, resulting in a hard crash of mupdf. Best wishes, Taco ___ 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 : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___
Re: [NTG-context] font-syn.lua error
On Wed, Nov 25, 2009 at 10:00 AM, Taco Hoekwater t...@elvenkind.com wrote: luigi scarso wrote: Using the C stack for recursion is the main problem. Pdfs with a large number of objects (annots) are likely to exhaust the stack, resulting in a hard crash of mupdf. can we make a good pdf with luatex to check this ? -- luigi ___ 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 : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___
Re: [NTG-context] font-syn.lua error
Thomas A. Schmitz wrote: On Nov 25, 2009, at 8:15 AM, luigi scarso wrote: 1. In evince under linux, the file looked fine, no problems were apparent. what about xpdf and ghostscript? Can you also try with mupdf ? That wasn't the point, I was not trying to give a comparative table of pdf-viewers. luatex was buggy, but some viewers displayed the pdf nonetheless. Doesn't make sense to test a dozen viewers because next time around, the subset which does or does not work may be totally different. the bug is that the x scale is zero and acrobat does not like that too much and simply quits rendering (old versions crash); it might be that other viewers then take some default the zero bug is just a side effect of rewriting backend code of luatex and is solved in upcoming 0.46 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 : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___
Re: [NTG-context] font-syn.lua error
Thomas A. Schmitz wrote: On Nov 22, 2009, at 10:19 PM, Hans Hagen wrote: that line says data_state = resolvers.data_state(), so resolvers has no data_state entry which in turn means that you run an old mtxrun, so maybe you need top copy mtxrun.lua manually to where it currently sits in yout path (as mtxrun) Just an afterthought to this problem: I discovered yesterday that the same file behaved quite differently in different viewers. It was a file compiled with the latest beta under linux, luatex 0.44, and with my own fonts. 1. In evince under linux, the file looked fine, no problems were apparent. 2. In Preview under OS X, the file showed only blank pages. 3. In Adobe Reader 9, both under linux and OS X, the file refused to open with a dialogue saying it was damaged and couldn't be repaired. So unfortunately, this is something we have to keep in mind when we test something and say works here. yes, it would be nice to have a document that includes all such bug triggers, but we need a volunteer for that (not context bugs, but graphical rendering issues) 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 : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___
Re: [NTG-context] first-setup.sh on MacOSX problem...
On Tue, Nov 24, 2009 at 15:24, Bernhard Rosensteiner wrote: Hello all, after my new OSX installation i did first-setup.sh as always but now i get: This is LuaTeX, Version beta-0.40.6-2009100310 (TeX Live 2009) (INITEX) \write18 enabled. (/Applications/ConTeXt/tex/texmf-context/tex/context/base/cont-en.tex ! I can't find file `context.tex'. l.16 \input context.tex Please type another input file name: Just a notice to all Snow Leopard users. I managed to reproduce the problem (I was sure there would be a problem, but people claimed that it worked that way). The easiest temporary patch is to remove --make in mtxrun call in first-setup.sh (and then make formats manually), but I will try to fix it. 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 : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___
Re: [NTG-context] font-syn.lua error
luigi scarso wrote: On Wed, Nov 25, 2009 at 10:00 AM, Taco Hoekwater t...@elvenkind.com wrote: luigi scarso wrote: Using the C stack for recursion is the main problem. Pdfs with a large number of objects (annots) are likely to exhaust the stack, resulting in a hard crash of mupdf. can we make a good pdf with luatex to check this ? I don't see why not, but I'll pass. I have enough to do already. Best wishes, Taco ___ 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 : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___
Re: [NTG-context] font-syn.lua error
On Wednesday 25 November 2009 09:54:36 luigi scarso wrote: That wasn't the point, I was not trying to give a comparative table of pdf-viewers. luatex was buggy, but some viewers displayed the pdf nonetheless. Doesn't make sense to test a dozen viewers because next time around, the subset which does or does not work may be totally different. Not dozen, only 2~3 but code independent .My choices are 1) xpdf (same codebase of luatex) 2)acroread (the most important viewer for pdf ) 3) ghostscript (also used by context ) They are all used / important for TeX community and printing house. I understood that xpdf has been replaced by poppler, a rewritten PDF rendering library (based originally on xpdf, however I am no authority). This library is the motor behind the viewers evince (gnome) and okular (kde). If this is different from the codebase used by luatex, should luatex eventually be migrated to popplar? Alan ___ 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 : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___
Re: [NTG-context] font-syn.lua error
Alan BRASLAU wrote: On Wednesday 25 November 2009 09:54:36 luigi scarso wrote: That wasn't the point, I was not trying to give a comparative table of pdf-viewers. luatex was buggy, but some viewers displayed the pdf nonetheless. Doesn't make sense to test a dozen viewers because next time around, the subset which does or does not work may be totally different. Not dozen, only 2~3 but code independent .My choices are 1) xpdf (same codebase of luatex) 2)acroread (the most important viewer for pdf ) 3) ghostscript (also used by context ) They are all used / important for TeX community and printing house. I understood that xpdf has been replaced by poppler, a rewritten PDF rendering library (based originally on xpdf, however I am no authority). This library is the motor behind the viewers evince (gnome) and okular (kde). If this is different from the codebase used by luatex, should luatex eventually be migrated to popplar? we only need a limited library, no rendering, only loading and inclusion, and the problems that were reported are related to rendering 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 : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___
Re: [NTG-context] font-syn.lua error
On Wednesday 25 November 2009 09:37:11 Taco Hoekwater wrote: Alan BRASLAU wrote: Maybe unrelated, but maybe a luatex error as well: transparency seems to work correctly when viewed with okular (same library as evince) but not when view with acroread, (including the windows version). What is 'not'? If you means that the rest of the page looks crappy, that is known Acrobat behavior. If you want all pages to look the same (crappy) in AR, use \TransparancyHack. If there is no transparancy at all, then there could be a problem within mkiv or luatex. No transparancy, or perhaps total transparancy, my test cannot tell as I am using transparancy in metafun to produce a gradient from .5white to black. Printing the page under acroread then hangs. Alan P.S. looks OK under xpdf. compass.pdf Description: Adobe PDF document ___ 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 : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___
Re: [NTG-context] font-syn.lua error
Alan BRASLAU wrote: On Wednesday 25 November 2009 09:37:11 Taco Hoekwater wrote: Alan BRASLAU wrote: Maybe unrelated, but maybe a luatex error as well: transparency seems to work correctly when viewed with okular (same library as evince) but not when view with acroread, (including the windows version). What is 'not'? If you means that the rest of the page looks crappy, that is known Acrobat behavior. If you want all pages to look the same (crappy) in AR, use \TransparancyHack. If there is no transparancy at all, then there could be a problem within mkiv or luatex. No transparancy, or perhaps total transparancy, my test cannot tell as I am using transparancy in metafun to produce a gradient from .5white to black. Printing the page under acroread then hangs. Odd file. Can you send me the source? I would like to play with it ___ 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 : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___
Re: [NTG-context] font-syn.lua error
On Wed, Nov 25, 2009 at 11:59 AM, Alan BRASLAU alan.bras...@cea.fr wrote: On Wednesday 25 November 2009 09:54:36 luigi scarso wrote: Not dozen, only 2~3 but code independent .My choices are 1) xpdf (same codebase of luatex) I understood that xpdf has been replaced by poppler, a rewritten PDF rendering library (based originally on xpdf, however I am no authority). This library is the motor behind the viewers evince (gnome) and okular (kde). If this is different from the codebase used by luatex, should luatex eventually be migrated to popplar? Alan If I understand it correctly, by default luatex is build with code taken from xpdf codebase but you can choose to use your system libpoppler . source/configure: --with-system-xpdf use installed poppler headers and library instead of xpdf (requires pkg-config) -- luigi ___ 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 : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___
Re: [NTG-context] font-syn.lua error
2009/11/25 Alan BRASLAU alan.bras...@cea.fr: If this is different from the codebase used by luatex, should luatex eventually be migrated to popplar? Yes, and you can already compile luatex with poppler (texlive does that). For more see my talk at EuroTeX 2009: http://www.oneiros.de/tex/papers/eurotex2009-pdflibs.pdf Best Martin ___ 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 : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___
Re: [NTG-context] font-syn.lua error
Alan BRASLAU wrote: On Wednesday 25 November 2009 09:37:11 Taco Hoekwater wrote: Alan BRASLAU wrote: Maybe unrelated, but maybe a luatex error as well: transparency seems to work correctly when viewed with okular (same library as evince) but not when view with acroread, (including the windows version). What is 'not'? If you means that the rest of the page looks crappy, that is known Acrobat behavior. If you want all pages to look the same (crappy) in AR, use \TransparancyHack. If there is no transparancy at all, then there could be a problem within mkiv or luatex. No transparancy, or perhaps total transparancy, my test cannot tell as I am using transparancy in metafun to produce a gradient from .5white to black. Printing the page under acroread then hangs. hard to see in a compressed file, next time use \nopdfcompression - 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 : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___
Re: [NTG-context] font-syn.lua error
Alan BRASLAU wrote: On Wednesday 25 November 2009 09:37:11 Taco Hoekwater wrote: Alan BRASLAU wrote: Maybe unrelated, but maybe a luatex error as well: transparency seems to work correctly when viewed with okular (same library as evince) but not when view with acroread, (including the windows version). What is 'not'? If you means that the rest of the page looks crappy, that is known Acrobat behavior. If you want all pages to look the same (crappy) in AR, use \TransparancyHack. If there is no transparancy at all, then there could be a problem within mkiv or luatex. No transparancy, or perhaps total transparancy, my test cannot tell as I am using transparancy in metafun to produce a gradient from .5white to black. a ca of 0.0055 is not that much but hard to track without source - 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 : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___
[NTG-context] hyphenation problem using |-| in composed words -- bug?
Hi, when using |-| in a word as a non exclusive dash, this produces wrong hyphenation. For example, the word »longer-word-to-be-hyphenated« should be hyphenated e.g. like this: longer- word- to- be- hy- phen- ated but actually it is hyphenated like this: longer -word -to -be -hy- phen- ated Using || instead of |-| works like expected, so using it in combination with \setuphyphenmark[sign=normal] could be considered a workaround. Sadly, that produces the same bad result. :-( Here's a minimal example: %\setuphyphenmark[sign=normal] \starttext \hsize 1em longer|-|word|-|to|-|be|-|hyphenated longer||word||to||be||hyphenated \stoptext TIA, olli -- Oliver Heins he...@sopos.orghttp://oliverheins.net/ http://blog.overheins.net/ F27A BA8C 1CFB B905 65A8 http://scriptorium-adp.de/ 2544 0F07 B675 9A00 D827 1024D/9A00D827 2004-09-24 -- gpg --recv-keys 0x9A00D827 Please avoid sending me Word or PowerPoint attachments: http://www.gnu.org/philosophy/no-word-attachments.html ___ 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 : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___
[NTG-context] Problem with font mapping
Hello again, I seem to be running into all sorts of font problems. Now my document has suddenly turned bold. For example, running the following code results in Test. being rendered in bold characters. \usemodule[simplefonts] \setmainfont[Adobe Garamond Pro] \starttext Test. \stoptext Running mtxrun --script font --list --pattern=*Garamond* --all reveals that there's something fishy about the font mapping: adobegaramondpro = agaramondprosemibold = AGaramondPro-Semibold.otf adobegaramondprobold = agaramondprosemibold = AGaramondPro-Semibold.otf adobegaramondprobolditalic = agaramondprosemibolditalic = AGaramondPro-SemiboldItalic.otf adobegaramondproitalic = agaramondprobolditalic = AGaramondPro-BoldItalic.otf adobegaramondpronormal = agaramondproregular = AGaramondPro-Regular.otf adobegaramondproregular = agaramondprobold = AGaramondPro-Bold.otf adobegaramondprosemibold = agaramondprosemibold = AGaramondPro-Semibold.otf agaramondprobold = agaramondprobold = AGaramondPro-Bold.otf agaramondprobolditalic = agaramondprobolditalic = AGaramondPro-BoldItalic.otf agaramondproitalic = agaramondproitalic = AGaramondPro-Italic.otf agaramondproregular = agaramondproregular = AGaramondPro-Regular.otf agaramondprosemibold = agaramondprosemibold = AGaramondPro-Semibold.otf agaramondprosemibolditalic = agaramondprosemibolditalic = AGaramondPro-SemiboldItalic.otf As you can see, agaramond... are mapped properly while adobegaramond... are mapped wrong. Changing \setmainfont[Adobe Garamond Pro] to \setmainfont[agaramondpro] fixes the issue but, still, I'd prefer to use the former (as I've done until now) since it's clearer. I'm running ConTeXt version 2009.11.24 10:13. Mika ___ 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 : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___
Re: [NTG-context] Metapost - Seems like weird behavior. Is it a bug?
Taco, thanks for the suggestions. I will try using intersectiontimes. It would be great if, as you said, this is solved with Metapost 2.0. Any idea when that version is coming out? Thanks. On Wed, Nov 25, 2009 at 2:47 AM, Taco Hoekwater t...@elvenkind.com wrote: Taco Hoekwater wrote: The solution is to add an explicit fix to Lint[4] just after its current assignment: Lint[4]:=(xpart Lint[4], 0); Even better is to not use intersectionpoint at all: use intersectiontimes instead. With that, you can select a point that is guaranteed to be on one of the two paths. Best wishes, Taco ___ 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 : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___ ___ 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 : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___
Re: [NTG-context] Problem with font mapping
Mika Ritola wrote: Hello again, I seem to be running into all sorts of font problems. Now my document has suddenly turned bold. For example, running the following code results in Test. being rendered in bold characters. \usemodule[simplefonts] \setmainfont[Adobe Garamond Pro] \starttext Test. \stoptext Running mtxrun --script font --list --pattern=*Garamond* --all reveals that there's something fishy about the font mapping: adobegaramondpro = agaramondprosemibold = AGaramondPro-Semibold.otf adobegaramondprobold = agaramondprosemibold = AGaramondPro-Semibold.otf adobegaramondprobolditalic = agaramondprosemibolditalic = AGaramondPro-SemiboldItalic.otf adobegaramondproitalic = agaramondprobolditalic = AGaramondPro-BoldItalic.otf adobegaramondpronormal = agaramondproregular = AGaramondPro-Regular.otf adobegaramondproregular = agaramondprobold = AGaramondPro-Bold.otf adobegaramondprosemibold = agaramondprosemibold = AGaramondPro-Semibold.otf agaramondprobold = agaramondprobold = AGaramondPro-Bold.otf agaramondprobolditalic = agaramondprobolditalic = AGaramondPro-BoldItalic.otf agaramondproitalic = agaramondproitalic = AGaramondPro-Italic.otf agaramondproregular = agaramondproregular = AGaramondPro-Regular.otf agaramondprosemibold = agaramondprosemibold = AGaramondPro-Semibold.otf agaramondprosemibolditalic = agaramondprosemibolditalic = AGaramondPro-SemiboldItalic.otf i cannot check it as i have no adobe garamond As you can see, agaramond... are mapped properly while adobegaramond... are mapped wrong. it all depends in what info is in the font ... familyname, weight etc and sometimes it's contradicting Changing \setmainfont[Adobe Garamond Pro] to \setmainfont[agaramondpro] fixes the issue but, still, I'd prefer to use the former (as I've done until now) since it's clearer. how recent is your version of mtxrun / mtx-font / font database? it has been a bit in flux last weeks - 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 : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___
Re: [NTG-context] Metapost - Seems like weird behavior. Is it a bug?
Curiouslearn wrote: Taco, thanks for the suggestions. I will try using intersectiontimes. It would be great if, as you said, this is solved with Metapost 2.0. Any idea when that version is coming out? Next summer ___ 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 : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___
Re: [NTG-context] font-syn.lua error
On Wed, Nov 25, 2009 at 11:02 AM, Taco Hoekwater t...@elvenkind.com wrote:
luigi scarso wrote:
can we make a good pdf with luatex to check this ?
I don't see why not, but I'll pass. I have enough to do already.
Maybe something like this
%\pdfcompresslevel0
%\pdfobjcompresslevel0
\setupinteraction[state=start]
\setupcolors[state=start]
\starttext
\noindent\dorecurse{10}{%
\pagereference[z\recurselevel]Foo\recurselevel\quad
}
\noindent\dorecurse{10}{%
(see \at{page}[z\recurselevel])\quad
}
\stoptext
No problem with mupdf.
--
luigi
___
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 : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___
Re: [NTG-context] font-syn.lua error
On Wed, Nov 25, 2009 at 12:09 PM, Alan BRASLAU alan.bras...@cea.fr wrote: No transparancy, or perhaps total transparancy, my test cannot tell as I am using transparancy in metafun to produce a gradient from .5white to black. Printing the page under acroread then hangs. Alan P.S. looks OK under xpdf. mupdf shows it completely different -- luigi attachment: compass.png___ 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 : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___
Re: [NTG-context] hyphenation problem using |-| in composed words -- bug?
To comment on myself:
Oliver Heins o...@sopos.org writes:
Hi,
when using |-| in a word as a non exclusive dash, this produces wrong
hyphenation.
[...]
longer
-word
-to
-be
-hy-
phen-
ated
This is a workaround:
\definetextmodediscretionary {-}
{\prewordbreak\discretionary{\hbox{-}}{}{\hbox{-}}\prewordbreak}
However, \setuphyphenmark[sign=normal] still does not work correctly.
Regards,
olli
--
Oliver Heins he...@sopos.orghttp://oliverheins.net/
http://blog.overheins.net/ F27A BA8C 1CFB B905 65A8
http://scriptorium-adp.de/ 2544 0F07 B675 9A00 D827
1024D/9A00D827 2004-09-24 -- gpg --recv-keys 0x9A00D827
Please avoid sending me Word or PowerPoint attachments:
http://www.gnu.org/philosophy/no-word-attachments.html
___
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 : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___
Re: [NTG-context] font-syn.lua error
luigi scarso wrote: On Wed, Nov 25, 2009 at 12:09 PM, Alan BRASLAU alan.bras...@cea.fr wrote: No transparancy, or perhaps total transparancy, my test cannot tell as I am using transparancy in metafun to produce a gradient from .5white to black. Printing the page under acroread then hangs. Alan P.S. looks OK under xpdf. mupdf shows it completely different my experience is that there are only a few viewers capable of dealing with transparencies (wrong clipping, wrong colors, etc) 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 : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___
Re: [NTG-context] font-syn.lua error
Hans Hagen wrote: luigi scarso wrote: On Wed, Nov 25, 2009 at 12:09 PM, Alan BRASLAU alan.bras...@cea.fr wrote: No transparancy, or perhaps total transparancy, my test cannot tell as I am using transparancy in metafun to produce a gradient from .5white to black. Printing the page under acroread then hangs. Alan P.S. looks OK under xpdf. mupdf shows it completely different I believe it is safe to say that that rendering is quite wrong. ;) my experience is that there are only a few viewers capable of dealing with transparencies (wrong clipping, wrong colors, etc) Same here. And actually, xpdf often does a better job than acroread (I suspect that the implementation of the colormodel AR switches to in that case is less-than-perfect) Best wishes, Taco ___ 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 : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___
Re: [NTG-context] font-syn.lua error
Taco Hoekwater wrote: Same here. And actually, xpdf often does a better job than acroread (I suspect that the implementation of the colormodel AR switches to in that case is less-than-perfect) also, acrobat has this 'simulate paper' mechanism that influences the rendering 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 : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___
Re: [NTG-context] Problem with font mapping
2009/11/25 Hans Hagen pra...@wxs.nl Mika Ritola wrote: Hello again, I seem to be running into all sorts of font problems. Now my document has suddenly turned bold. For example, running the following code results in Test. being rendered in bold characters. \usemodule[simplefonts] \setmainfont[Adobe Garamond Pro] \starttext Test. \stoptext Running mtxrun --script font --list --pattern=*Garamond* --all reveals that there's something fishy about the font mapping: adobegaramondpro = agaramondprosemibold = AGaramondPro-Semibold.otf adobegaramondprobold = agaramondprosemibold = AGaramondPro-Semibold.otf adobegaramondprobolditalic = agaramondprosemibolditalic = AGaramondPro-SemiboldItalic.otf adobegaramondproitalic = agaramondprobolditalic = AGaramondPro-BoldItalic.otf adobegaramondpronormal = agaramondproregular = AGaramondPro-Regular.otf adobegaramondproregular = agaramondprobold = AGaramondPro-Bold.otf adobegaramondprosemibold = agaramondprosemibold = AGaramondPro-Semibold.otf agaramondprobold = agaramondprobold = AGaramondPro-Bold.otf agaramondprobolditalic = agaramondprobolditalic = AGaramondPro-BoldItalic.otf agaramondproitalic = agaramondproitalic = AGaramondPro-Italic.otf agaramondproregular = agaramondproregular = AGaramondPro-Regular.otf agaramondprosemibold = agaramondprosemibold = AGaramondPro-Semibold.otf agaramondprosemibolditalic = agaramondprosemibolditalic = AGaramondPro-SemiboldItalic.otf i cannot check it as i have no adobe garamond As you can see, agaramond... are mapped properly while adobegaramond... are mapped wrong. it all depends in what info is in the font ... familyname, weight etc and sometimes it's contradicting I downgraded to the current (2009.10.27 16:35) version of ConTeXt to see if the mappings are different, and this is the result: adobegaramondpro = Adobe Garamond Pro Bold = AGaramondPro-Bold.otf adobegaramondprobold = Adobe Garamond Pro Bold = AGaramondPro-Bold.otf adobegaramondprobolditalic = Adobe Garamond Pro Bold Italic = AGaramondPro-BoldItalic.otf adobegaramondproitalic = Adobe Garamond Pro Italic = AGaramondPro-Italic.otf adobegaramondproregular = Adobe Garamond Pro Regular = AGaramondPro-Regular.otf adobegaramondprosemibold = Adobe Garamond Pro Semibold = AGaramondPro-Semibold.otf adobegaramondprosemibolditalic = Adobe Garamond Pro Semibold Italic = AGaramondPro-SemiboldItalic.otf agaramondprobold = AGaramondPro-Bold = AGaramondPro-Bold.otf agaramondprobolditalic = AGaramondPro-BoldItalic = AGaramondPro-BoldItalic.otf agaramondproitalic = AGaramondPro-Italic = AGaramondPro-Italic.otf agaramondproregular = AGaramondPro-Regular = AGaramondPro-Regular.otf agaramondprosemibold = AGaramondPro-Semibold = AGaramondPro-Semibold.otf agaramondprosemibolditalic = AGaramondPro-SemiboldItalic = AGaramondPro-SemiboldItalic.otf In other words, the mappings seem to be fine here (though I'm not sure about the first one). Thus, it seems that some change in ConTeXt has broken the font. Changing \setmainfont[Adobe Garamond Pro] to \setmainfont[agaramondpro] fixes the issue but, still, I'd prefer to use the former (as I've done until now) since it's clearer. how recent is your version of mtxrun / mtx-font / font database? it has been a bit in flux last weeks Do you mean the database that's generated by mtxrun --script font --reload? Updating it didn't solve the problem. Mika ___ 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 : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___
Re: [NTG-context] font-syn.lua error
On Wed, Nov 25, 2009 at 7:18 PM, Taco Hoekwater t...@elvenkind.com wrote: I believe it is safe to say that that rendering is quite wrong. ;) The problem is that pratically this pdf is wrong because Acroread is not able to print. AR also shows something different from xpdf , gs shows the same of AR too mupdf show something completely different, and I believe from experience that xpdf is right, but at this point the only thing that I care is to understand what is wrong with AR given that xpdf is right. The only solution is to uncompress and study the pdf and the source -- which we don't have . mupdf tools, xpdf tools, and gs can help in this: it seems that xref is a bit messy, so it can be a problem of metapost too, or maybe not at all. In this situation I don't care about poppler, evince, okular, foxit etc -- all marvelous program, but they can't help more than the others. -- luigi ___ 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 : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___
Re: [NTG-context] How to show footer only with chapter head
Hi Elliot, Please look into the big ConTeXt manual on page 81: Suppose that a default setup looks like this: \setupheadertexts[pagenumber] \setupfootertexts[chapter][paragraph] At the first page of new chapters this may look not too good. Therefore we could state: \setuphead[chapter][header=empty,footer=empty] However if we use it in this way we loose the pagenumber. A more adequate solution is: \definetext[chapter][footer][pagenumber] with: \setuphead[chapter][header=high,footer=chapter,page=right] Kind regards Willi On Nov 24, 2009, at 9:09 PM, Elliot Clifton wrote: Hi, I have page numbers and chapter headings displayed in my document's header. The header is suppressed on a page with a chapter head i.e. \setuphead[chapter][header=high] therefore I want a footer on these pages to display the page number. The footer should disabled on all other pages. I've tried, \setuphead[chapter][footer=normal] but it overrides \setupfooter[state=none] everywhere, not only on chapter pages. Any ideas? TIA, Elliot __ _ 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 : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net __ _ ___ 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 : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___
[NTG-context] Layout - once again!
Why does the following does not center the text? I am choosing a letter size paper which is 8.5 inches wide. I have both margins at 1.5in and all other distances equal to 0 in. Should the text be not centered. Thanks. \setuppapersize[letter][letter] \setuplayout[leftmargin=1.5in,rightmargin=1.5in,leftedge=0in,rightedge=0in,leftmargindistance=0in,rightmargindistance=0in,leftedgedistance=0in,rightedgedistance=0in,width=5.5in] \starttext \showlayout \input tufte \stoptext ___ 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 : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___
Re: [NTG-context] Layout - once again!
On Thu, Nov 26, 2009 at 05:19, Curiouslearn wrote: Why does the following does not center the text? I am choosing a letter size paper which is 8.5 inches wide. I have both margins at 1.5in That's width of box called margin (the one where you put side notes etc). You need to set backspace=1.5in and that should suffice. and all other distances equal to 0 in. Should the text be not centered. No, because backspace=1in by default, so what you thought of as left margin is only 1in wide and the right one probably 2in then. Mojca \setuppapersize[letter][letter] \setuplayout[leftmargin=1.5in,rightmargin=1.5in,leftedge=0in,rightedge=0in,leftmargindistance=0in,rightmargindistance=0in,leftedgedistance=0in,rightedgedistance=0in,width=5.5in] \starttext \showlayout \input tufte \stoptext ___ 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 : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___
Re: [NTG-context] hyphenation problem using |-| in composed words -- bug?
Hi olli, Oliver Heins wrote: To comment on myself: Oliver Heins o...@sopos.org writes: Hi, when using |-| in a word as a non exclusive dash, this produces wrong hyphenation. Verified. Same problems here, in both mkii and mkiv. Best wishes, Taco ___ 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 : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___
