Example ConTeXt document: PS output
I've just installed ConTeXt "minimal" and had a look at "ConTeXt, The Manual". I typed in the example document that starts at the bottom of page 13 (called it eg.tex) and ran context. It produced the file eg.pdf and I notice that it ran luatex with the option "--backend=pdf". Thanks, those who have done massive amounts of advanced work on ConTeXt and luatex, huge projects which are costing me nothing. But, I have a problem. I have a PostScript printer. I'd prefer not to have to run pdf2ps. How can ps output be produced directly? "context --backend=ps eg" doesn't do it and there is nothing about --backend or other options in the index, of "ConTeXt, The Manual", as far as I can see. There's no Reference/en/backend on the wiki.
I've just installed ConTeXt "minimal" and had a look at "ConTeXt, The Manual". I typed in the example document that starts at the bottom of page 13 (called it eg.tex) and ran context. It produced the file eg.pdf and I notice that it ran luatex with the option "--backend=pdf".
Thanks, those who have done massive amounts of advanced work on ConTeXt and luatex, huge projects which are costing me nothing. But, I have a problem.
I have a PostScript printer. I'd prefer not to have to run pdf2ps. Does not AdobeReader help here ?
How can ps output be produced directly? "context --backend=ps eg" doesn't do it and there is nothing about --backend or other options in the index, of "ConTeXt,
On Fri, Jul 9, 2010 at 5:46 PM, Michael Talbot-Wilson
2010/7/9 luigi scarso
pdf and dvi are the only backend . In mkiv (I suppose you are using mkiv because of "context" ) the pdf backend is actually the only backend.
Luigi has summarized it pretty much. Even though LuaTeX can actually produce DVI, I'm not sure if it can be called to do so from ConTeXt. On the other hand, MkII provides --dvi switch which actually produces ps using dvips, so you can try that. Regards, -- Vedran Miletić
On Fri, 9 Jul 2010, Vedran Mileti�~G wrote:
2010/7/9 luigi scarso
: pdf and dvi are the only backend . In mkiv (I suppose you are using mkiv because of "context" ) the pdf backend is actually the only backend. Luigi has summarized it pretty much. Even though LuaTeX can actually produce DVI, I'm not sure if it can be called to do so from ConTeXt.
On the other hand, MkII provides --dvi switch which actually produces ps using dvips, so you can try that.
Thanks for your reply. Both. But Luigi seems to say LuaTeX can NOT actually produce DVI. Or is that just ConTeXt? With "minimals" I can't run luatex directly. It wants a format file that is not there. Presumably "maximals" has it. So I can't try using "luatex --backend=dvi hello_world" directly on my hello_world.tex to see if that option's supported. The "LuaTeX Reference" has not yet achieved an index and I don't know where else a list of luatex command line options might be found. But if there is no dvi or final ps output I think perhaps ConTeXt is not for me just now. Something Unix-oriented would be more usable. Something alien will throw up other problems. Oh, yes. May have a look at MkII. But does it use LuaTeX? The possibility of easy macros in Lua rather than difficult macros in TeX would be one attraction of ConTeXt. Maybe Eplain LuaTeX is what I need. Thanks again.
On Sat, Jul 10, 2010 at 4:46 AM, Michael Talbot-Wilson
Thanks for your reply. Both. But Luigi seems to say LuaTeX can NOT actually produce DVI. Or is that just ConTeXt? LuaTex aims to become the next pdftex, and it already has a dvi output mode. ConText mkiv today is very pdf oriented, it doesn't support dvi very well, if at all.
With "minimals" I can't run luatex directly. It wants a format file that is not there. You can build one: see files under minimals-beta/tex/texmf-context/tex/generic/context exp. luatex-plain.tex
Presumably "maximals" has it. So I can't try using "luatex --backend=dvi hello_world" directly on my hello_world.tex to see if that option's supported. The option is --output-format --output-format=FORMAT use FORMAT for job output; FORMAT is 'dvi' or 'pdf' If CACHE is the dir of your cache where there are the formats (ie CACHE="/opt/luatex/minimals-beta-eurotex-2010/tex/texmf-cache/luatex-cache/context/8951e8d562c3f685559ce86173519cf6/formats" you can try just now with
luatex --fmt="$CACHE/cont-en" --lua="$CACHE/cont-en.lui" --backend=dvi "test.tex"
The "LuaTeX Reference" has not yet achieved an index and I don't know where else a list of luatex command line options might be found.
try to search inside the pdf then with xpdf
But if there is no dvi or final ps output I think perhaps ConTeXt is not for me just now. Something Unix-oriented would be more usable. Something alien will throw up other problems.
I'm using Linux from 20years and I must to say that minimal is full Unix oriented (I always though that with context Hans uses Windows in an Unix way) I don't understand why you are so tied to dvi. Even postscript is a bit outdated as final output: pdf is the standard-defacto and convert pdf to ps is really easy with the suite of programs from xpdf or acrobat reader. If you like the Unix way a bash script is trivial.
Oh, yes. May have a look at MkII. But does it use LuaTeX?
no, it uses pdftex
The possibility of easy macros in Lua rather than difficult macros in TeX would be one attraction of ConTeXt. Really True (I sould say TRUE) . Maybe Eplain LuaTeX is what I need. No sure: mkiv adds a lots of lua macros that you should rewrite by yourself then
-- luigi
On Sat, 10 Jul 2010, Michael Talbot-Wilson wrote:
Oh, yes. May have a look at MkII. But does it use LuaTeX? The possibility of easy macros in Lua rather than difficult macros in TeX would be one attraction of ConTeXt. Maybe Eplain LuaTeX is what I need.
Let me correct that. Confused ravings. I was really looking for (1) font management making it easier to install new and unusual fonts without delving up to my armpits in tfm, pk, whatever, (2) something with Metapost more integrated, allowing easy placement of vector graphics in the document and allowing them to be defined within the document text file. It seemed momentarily that ConTeXt might be one way, and since there was an old version called MkII and a new version called MkIV, that MkIV was a sane place to start. ___________________________________________________________________________________ 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 ___________________________________________________________________________________
On Sat, Jul 10, 2010 at 5:32 AM, Michael Talbot-Wilson
On Sat, 10 Jul 2010, Michael Talbot-Wilson wrote:
Oh, yes. May have a look at MkII. But does it use LuaTeX? The possibility of easy macros in Lua rather than difficult macros in TeX would be one attraction of ConTeXt. Maybe Eplain LuaTeX is what I need.
Let me correct that. Confused ravings. I was really looking for (1) font management making it easier to install new and unusual fonts without delving up to my armpits in tfm, pk, whatever, (2) something with Metapost more integrated, allowing easy placement of vector graphics in the document and allowing them to be defined within the document text file.
It seemed momentarily that ConTeXt might be one way, and since there was an old version called MkII and a new version called MkIV, that MkIV was a sane place to start.
You have dropped dvi and ps constrains, so without no doubt context mkiv is the optimal choice. -- luigi
On Sat, 10 Jul 2010, luigi scarso wrote:
Let me correct that. Confused ravings. I was really looking for (1) font management making it easier to install new and unusual fonts without delving up to my armpits in tfm, pk, whatever, (2) something with Metapost more integrated, allowing easy placement of vector graphics in the document and allowing them to be defined within the document text file. ... You have dropped dvi and ps constrains, so without no doubt context mkiv is the optimal choice.
Running I think any browser on any Linux system, if I see a PDF file on the Web and click on print, and then print to a file, I automatically finish up with a .ps file. Which I can display with gv. The PDF format was all the time redundant. It may be that the graphic arts trade has switched to PDF as its standard, did long ago make that switch, but no-one told my printer. And even I prefer to avoid unnecessary conversions of image formats when I only want to print images. Using Photoshop I save as EPS, switch to Linux, run eplain, print a PostScript image (and text) on a PostScript printer, and that's the end of it. No double conversion of images, with the risk of degrading image quality. Or with the superstition that there could be such a risk. I'm not competent to debate the merits of PDF versus PS but I know what I want. I would like the high-level conveniences of ConTeXt, the ones I mentioned, but they don't supersede the rest. The luatex manpage in luatex-beta-0.60.2.tar.bz2 says: "In DVI mode, luaTeX can be used as a complete replacement for the TeX engine."
Hi, On 07/10/2010 07:46 AM, Michael Talbot-Wilson wrote:
Running I think any browser on any Linux system, if I see a PDF file on the Web and click on print, and then print to a file, I automatically finish up with a .ps file. Which I can display with gv. The PDF format was all the time redundant.
I can print that file directly from the pdf reader in that case (and I have a fairly standard PostScript printer), so from my point of view it is .ps that is the redundant format.
And even I prefer to avoid unnecessary conversions of image formats when I only want to print images. Using Photoshop I save as EPS, switch to Linux, run eplain, print a PostScript image (and text) on a PostScript printer, and that's the end of it.
Not that I want to criticize you workflow, if it works for you, that it is fine and there is no need to change it. But you could have saved as PNG, JPG, or PDF instead, and there would not be a need for conversion.
I would like the high-level conveniences of ConTeXt, the ones I mentioned, but they don't supersede the rest.
The luatex manpage in luatex-beta-0.60.2.tar.bz2 says:
"In DVI mode, luaTeX can be used as a complete replacement for the TeX engine."
In DVI mode, luatex can be used to replace TeX, yes. But in that case, you loose some important new features, because they are not supported by DVI format (opentype fonts, unicode support). For that reason, Hans decided not to support DVI mode for luatex in context MkIV. <side note> Talking as a luatex developer: If you want something better than what you have, you will have to be prepared to make some changes yourself as well. Life is too short for us freeware developers to keep supporting all existing setups on top of trying to improve things. Writing extensions to the DVI format (and all its processing tools) seemed like a waste of my time to me especially since everything we wanted to do in luatex is supported by PDF. You can, however, use context MkII ('texexec') which uses pdftex, and still have some of your wishes by making it output DVI files: texexec --backend=dvi ... I don't recall whether texexec calls dvips automatically, you probably have to do that manually. You won't be able to use OpenType fonts in that case and Unicode support will be somewhat dodgy, but you will still get the tight document-level integration with metapost that is always provided in context. Best wishes, Taco
2010/7/10 Michael Talbot-Wilson
Running I think any browser on any Linux system, if I see a PDF file on the Web and click on print, and then print to a file, I automatically finish up with a .ps file. Which I can display with gv. The PDF format was all the time redundant.
No. Only nobody puts a PDF RIP into consumer printers. The situation is completely reversed with printing houses: There you will have problems getting PostScript printed.
I'm not competent to debate the merits of PDF versus PS but I know what I want.
:-)
I would like the high-level conveniences of ConTeXt, the ones I mentioned, but they don't supersede the rest.
The ConTeXt team will not spend much effort (if any) to make MkIV run with dvi(ps). So stop whining and show us your patches. :-)
"In DVI mode, luaTeX can be used as a complete replacement for the TeX engine."
Yes. But MkIV needs much more then DVI and currently aims at PDF. Best Martin
On Sat, 10 Jul 2010, Michael Talbot-Wilson wrote:
On Sat, 10 Jul 2010, Michael Talbot-Wilson wrote:
Oh, yes. May have a look at MkII. But does it use LuaTeX? The possibility of easy macros in Lua rather than difficult macros in TeX would be one attraction of ConTeXt. Maybe Eplain LuaTeX is what I need.
Let me correct that. Confused ravings. I was really looking for (1) font management making it easier to install new and unusual fonts without delving up to my armpits in tfm, pk, whatever, (2) something with Metapost more integrated, allowing easy placement of vector graphics in the document and allowing them to be defined within the document text file.
It seemed momentarily that ConTeXt might be one way, and since there was an old version called MkII and a new version called MkIV, that MkIV was a sane place to start.
You can try ConTeXt with XeTeX engine. Aditya
On Sat, Jul 10 2010, Michael Talbot-Wilson wrote:
I have a PostScript printer. I'd prefer not to have to run pdf2ps.
Hello, Normally, the printing system (cups for example) will run pdf2ps for you, and you should be able to do something like "lpr file.pdf" without any problems.
How can ps output be produced directly?
You can make a script "context-ps", for example like this: #!/bin/bash context "$1" pdf2ps "${1/.tex/}.pdf" Cheers, Peter -- Contact information: http://pmrb.free.fr/contact/
On Fri, Jul 9, 2010 at 17:46, Michael Talbot-Wilson wrote:
I have a PostScript printer. I'd prefer not to have to run pdf2ps.
Unrelated to the question of PS output of ConTeXt: I have a PostScript printer (at home and in the office) as well, but my general impression has always been as if PDFs were printed "natively". That is: printer sometimes has problem and doesn't know how to print some complex vector graphics properly; it prints very fast; if I use a different driver (a "normal" instead of PostScript one) then some PDF files that would come out corrupted are printed properly etc. I may be biased since I'm using Mac that comes with a relatively good (native?) support for PDFs, but I remember the "problems" with corrupted PDFs on PS printer from Windows. It is true that I always print from GUI as opposed to simply copying the file to printer from command line ... but I'm still not sure if avoiding PDF for all costs makes sense or not. Expressed in other words: what usually happens when one sends PDF to PostScript printer? Does it print the document almost-natively or not? This page says: http://www.adobe.com/print/features/psvspdf/ "In order for a PDF file to be printed, however, the printer still needs to render the PDF objects to the page, and a PostScript printer is still the most reliable way to do this. Some PostScript printers understand not only the PostScript language, but also PDF files natively. And some printers, using a technology we call Extreme, actually convert all jobs into a PDF file prior to printing. (Agfa, Creo, Heidelberg, and Scitex have all announced print workflows based on Extreme.)" Mojca
2010/7/10 Mojca Miklavec
avoiding PDF for all costs makes sense or not. Expressed in other words: what usually happens when one sends PDF to PostScript printer? Does it print the document almost-natively or not?
Typically your viewer (e.g. Adobe Reader) or your printing system (e.g. CUPS) converts it to PostScript. Or your printer has a PDF RIP (rare). Then there are two possibilities: - the PDF RIP converts the PDF to PostScript and feeds it to it's PostScript RIP (this is the norm with most Adobe PDF RIPs). This is the reason that printers with PDF RIPs often also have a harddisc. - the PDF gets directly interpreted by a PDF RIP (JAWS, Harlequin and newer Adobe PDF RIPs do this). Best Martin
On Sun, Jul 11, 2010 at 00:21, Martin Schröder
2010/7/10 Mojca Miklavec
: avoiding PDF for all costs makes sense or not. Expressed in other words: what usually happens when one sends PDF to PostScript printer? Does it print the document almost-natively or not?
Typically your viewer (e.g. Adobe Reader) or your printing system (e.g. CUPS) converts it to PostScript.
http://www.csb.yale.edu/userguides/image/adobe.html Acrobat reader can be used as PDF-to-PS converter. With HP Postscript printer with Jetdirect interface I can send directly PS file to printer, via FTP protocol IIRC.
On Sun, 11 Jul 2010, Martin Schr�der wrote:
2010/7/10 Mojca Miklavec
: avoiding PDF for all costs makes sense or not. Expressed in other words: what usually happens when one sends PDF to PostScript printer? Does it print the document almost-natively or not?
Typically your viewer (e.g. Adobe Reader) or your printing system (e.g. CUPS) converts it to PostScript.
Or your printer has a PDF RIP (rare). Then there are two possibilities: - the PDF RIP converts the PDF to PostScript and feeds it to it's PostScript RIP (this is the norm with most Adobe PDF RIPs). This is the reason that printers with PDF RIPs often also have a harddisc. - the PDF gets directly interpreted by a PDF RIP (JAWS, Harlequin and newer Adobe PDF RIPs do this).
Thanks for this info. As I said, I can use pdf2ps, or CUPS will. (OT, but for me CUPS is presently out of action and I'm copying PS files directly to /dev/usb/lp0. A handshake/signalling problem on the side of the LaserJet 4050, I suspect.) Yes, one can create PDF output, and convert it to PS to print it, but I don't feel good about that when the doc contains images. There is an unnecessary conversion. And the reverse, ps2pdf, is possible and probably better. The idea of PDF as more device-independent than PS...? If I convert from .RAF to .PSD to .PDF to .PS the last step, to .PS, is fundamental, that's what the printer has to have, but the .PDF step is, to repeat, redundant. If the text processor generates PS I don't have to convert images to PDF. What can perhaps be said is that PDF is a more tightly controlled format and that the incompatibilities that can arise between prepress and press don't, there's no need to overlay DSC conventions because there is intrinsically less flexibility and less programmability. That fact, that there is greater restriction and control over the workflow, is perhaps of advantage to the more monetized side of all this. In that sense, and perhaps in that sense alone, PDF is not redundant, has a role. If Han The Thanh wants to generate PDF and calls a program pdftex I'm not going to complain. It is wholly admirable, absolutely brilliant. It is just that what he wants to do doesn't fit in with what I want to do. That's fine, there's a warning up front, I decide. But I was considering something else, which for some reason is not called pdfConTeXt, has another name. It treats PDF as fundamental when it's not, it's remedial. For some. I just hope this hasn't happened because luatex started as pdftex and for no better reason. Now (not addressed to Mojca), please don't be a smartarse and tell me (again) that this is all volunteer work and to send in patches, a new Device Independent file definition and implementation for Unicode. I'm full of admiration for you guys with the giant IQs who have created ConTeXt in tea breaks and at night, never taken a second of time from the employer, publishing house or university or hairdressing salon proprietor that pays you. But I don't pretend to be in that class. I'm just a mental midget. And I have other things to do. It ain't my project. Something else is.
Or your printer has a PDF RIP (rare).
Rare.
Now (not addressed to Mojca), please don't be a smartarse and tell me (again) that this is all volunteer work and to send in patches, a new Device Independent file definition and implementation for Unicode. I'm full of admiration for you guys with the giant IQs who have created ConTeXt in tea breaks and at night, never taken a second of time from the employer, publishing house or university or hairdressing salon proprietor that pays you. But I don't pretend to be in that class. I'm just a mental midget. And I have other things to do. It ain't my project. Something else is.
Maybe LuaLaTeX should work for you. Ivo Solnicky
2010/7/11 Ivo Solnický
Now (not addressed to Mojca), please don't be a smartarse and tell me (again) that this is all volunteer work and to send in patches, a new Device Independent file definition and implementation for Unicode. I'm full of admiration for you guys with the giant IQs who have created ConTeXt in tea breaks and at night, never taken a second of time from the employer, publishing house or university or hairdressing salon proprietor that pays you. But I don't pretend to be in that class. I'm just a mental midget. And I have other things to do. It ain't my project. Something else is.
Maybe LuaLaTeX should work for you. But even so there is a dvi-to-ps step to do, which is pratically the same of pdf-to-ps in context mkiv.
-- luigi
Am 2010-07-11 um 19:39 schrieb luigi scarso:
Maybe LuaLaTeX should work for you. But even so there is a dvi-to-ps step to do, which is pratically the same of pdf-to-ps in context mkiv.
I suggest to use plain PostScript; there are even layout frameworks* for that. You need just some PS files, no installation, no intermediate format: Write PS code and copy it to your printer. Hm, but the printer must convert PS to its internal pixel format, that means a lossy conversion... *) http://www.tinaja.com/post01.asp#gonzo (I used that once for auto-generating simple newspaper ads.) One of the major advantages of plain PostScript over PDF is, that PS is a complete programming language and you can even write your own printer-destroying virus. Nice! Greetlings from Lake Constance! Hraban --- http://www.fiee.net/texnique/ http://wiki.contextgarden.net https://www.cacert.org (I'm an assurer)
On Sun, Jul 11, 2010 at 10:37:01PM +0200, Henning Hraban Ramm wrote:
Am 2010-07-11 um 19:39 schrieb luigi scarso:
Maybe LuaLaTeX should work for you. But even so there is a dvi-to-ps step to do, which is pratically the same of pdf-to-ps in context mkiv.
I suggest to use plain PostScript; there are even layout frameworks* for that. You need just some PS files, no installation, no intermediate format: Write PS code and copy it to your printer. Hm, but the printer must convert PS to its internal pixel format, that means a lossy conversion...
*) http://www.tinaja.com/post01.asp#gonzo (I used that once for auto-generating simple newspaper ads.)
One of the major advantages of plain PostScript over PDF is, that PS is a complete programming language and you can even write your own printer-destroying virus. Nice!
SUSE had (have?) a graphical menu extension to GRUB boot loader written in PostScript. Don't ask me why I remembered this now, but I always found it one of most weird uses of PostSscript I've ever seen. Regards, Khaled -- Khaled Hosny Arabic localiser and member of Arabeyes.org team Free font developer
Am 2010-07-11 um 22:53 schrieb Khaled Hosny:
SUSE had (have?) a graphical menu extension to GRUB boot loader written in PostScript. Don't ask me why I remembered this now, but I always found it one of most weird uses of PostSscript I've ever seen.
NextStep's whole screen graphics was DisplayPostScript - in NS's successor OSX it became PDF (Aqua is based on a PDF graphics model; didn't research what's left of it today). I read, PostScript was also used for industrial robotics, because it's geometrical calculations were unique. Greetlings from Lake Constance! Hraban --- http://www.fiee.net/texnique/ http://wiki.contextgarden.net https://www.cacert.org (I'm an assurer)
On 11-7-2010 7:39, luigi scarso wrote:
2010/7/11 Ivo Solnický
: Now (not addressed to Mojca), please don't be a smartarse and tell me (again) that this is all volunteer work and to send in patches, a new Device Independent file definition and implementation for Unicode. I'm full of admiration for you guys with the giant IQs who have created ConTeXt in tea breaks and at night, never taken a second of time from the employer, publishing house or university or hairdressing salon proprietor that pays you. But I don't pretend to be in that class. I'm just a mental midget. And I have other things to do. It ain't my project. Something else is.
Maybe LuaLaTeX should work for you. But even so there is a dvi-to-ps step to do, which is pratically the same of pdf-to-ps in context mkiv.
one of the reasons behind pdf is that it takes the programming language out of ps which means (1) better portability, (2) faster rendering in addition to that pdf provides a couple of goodies irrelevant to printers (annotations and such) dvi as outputformat is fine, but you then need to inject extra code for each (fundamentally) different backend tex + specials -> dvi -> ps -> pdf tex + specials -> dvi -> pdf tex + literals -> pdf (pdftex) now, as ps is seldom needed as final format it makes no sense generate it (and going from pdf -> ps is easy) using specials (inlined code) is no fun but has alway sbeen supported in mkii (spec-* files) using an intermediate layer in mkiv we have tex -> pdf so no specials and hardly any literals at the tex which is much cleaner; of course there can be more backends but a ps one is unlikely although in principle mkiv could be made to provide dvi to be fed in some backend driver i see no advantage in that Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
participants (13)
-
Aditya Mahajan
-
Hans Hagen
-
Henning Hraban Ramm
-
Ivo Solnický
-
Khaled Hosny
-
luigi scarso
-
Martin Schröder
-
Michael Talbot-Wilson
-
Mojca Miklavec
-
Peter Münster
-
Taco Hoekwater
-
Vedran Miletić
-
Vnpenguin