Some packages like w3m-img, fim, lsix etc can be used to show the images directly on the terminal itself on linux.
I am not talking about converting the image into an ASCII character version and showing it but the image itself which looks proper without any the artifacts.
so how do these programs actually draw the images onto the terminal?
I've used Feh in the past. It should be already installed on popular Linux distributions. To use it, simply do the following:
feh your-image.jpeg
In the past, Ghostscript used to incorporate these Apple Imagewriter devices: iwhi, iwlo, and iwlq. The version I had been using is gs 8.7 which is not 64-bit compliant. macOS Catalina cannot use it or any other 32 bit code, so printing to those devices fails.
More recent versions including the most recent Ghostscript 9.27 omit those devices. I don't know when they were omitted or why but it seems to be a while ago. Worse, I don't know how they get incorporated in Ghostscript. Other than building gs from its source code, which I have done, I don't know where to begin. The new Ghostscript 9.27 itself works fine in macOS Catalina. It includes many "built-in" devices but the ImageWriter devices I need are absent.
The drivers and Ghostscript were originally obtained from the Linux Foundation's Open Printing website: https://openprinting.org/printer/Apple/Apple-ImageWriter_II, but they were bundled and distributed in a package form that recent macOS versions cannot handle. That web page also indicates the drivers are "Type: Ghostscript built-in" which it no longer is in recent versions.
Here is gs -h using the installed 32 bit version:
GPL Ghostscript 8.71 (2010-02-10)
Copyright (C) 2010 Artifex Software, Inc. All rights reserved.
Usage: gs [switches] [file1.ps file2.ps ...]
Most frequently used switches: (you can use # in place of =)
-dNOPAUSE no pause after page | -q `quiet', fewer messages
-g<width>x<height> page size in pixels | -r<res> pixels/inch resolution
-sDEVICE=<devname> select device | -dBATCH exit after last file
-sOutputFile=<file> select output file: - for stdout, |command for pipe,
embed %d or %ld for page #
Input formats: PostScript PostScriptLevel1 PostScriptLevel2 PostScriptLevel3 PDF
Default output device: bbox
Available devices:
alc1900 <snip> inferno iwhi iwlo iwlq jetp3852 jj100 <many other devices> <snip>
Search path:
. : %rom%Resource/Init/ : %rom%lib/ :
/usr/local/share/ghostscript/8.71/Resource/Init :
/usr/local/share/ghostscript/8.71/lib :
/usr/local/share/ghostscript/8.71/Resource/Font :
/usr/local/share/ghostscript/fonts :
/usr/local/share/fonts/default/ghostscript :
/usr/local/share/fonts/default/Type1 :
/usr/local/share/fonts/default/TrueType : /usr/lib/DPS/outline/base :
/usr/openwin/lib/X11/fonts/Type1 : /usr/openwin/lib/X11/fonts/TrueType :
/usr/share/cups/fonts
Initialization files are compiled into the executable.
For more information, see /usr/local/share/ghostscript/8.71/doc/Use.htm.
Please report bugs to bugs.ghostscript.com.
iMac4:ghostscript-9.27 john$
The obvious sticking point is right there in front of me: "Initialization files are compiled into the executable." I know that, but what initialization files (if any) need to be included or modified to ensure their incorporation in the build? I have printer PPDs for the ImageWriter. They're just text files, and I think they would be required. Should they? How?
The only way I have attempted to build gs from source is to use ./configure followed by make That begins a long compilation process that takes a few minutes, and results in an executable gs that works fine in Catalina. The problem is it does not include the drivers I want. Attempting to print to that printer results in it printing "Unknown device: iwhi" in straight ASCII text (not bitmapped).
By now it ought to be painfully obvious I'm well over my head and don't know where to turn. Can anyone point me in the right direction from here?
Some background can be found here: Apple ImageWriter printer installation in… - Apple Community
. I wrote it. Some of its links are dead. If a picture doesn't load and you want to see it, click on it (it's a site problem).
A recent Discussion describing this dilemma is here: 32-bit ghostscript, required for ImageWriter and other printers using CUPS
The devices quoted were removed in this commit If you need them then you should be able to :
Clone our git repository, help on this is here
git checkout a87e380acd5e326f7d4e4380348bac393fac3058
copy the ghostpdl/devices/gdevadmp.c file somewhere convenient
git checkout master (or if you want a tagged release rather than the bleeding-edge code, git checkout ghostpdl-9.27 for example)
copy the saved file back to ghostpdl/devices/gdevadmp.c
Undo the changes in contrib.mak, configure.ac and unix-gcc.mak
(using the link to the gitweb you can see the diffs, they are not
extensive)
In the ghostpdl directory: ./autogen.sh then make
That all assumes you have a working C compiler (gcc, make etc) and development environment, but you say you've already built GS from source so that should be fine. The end result should be a woking Ghostscript with the additional device built in.
This:
Initialization files are compiled into the executable.
refers to the PostScript initialisation files, and won't help you with devices which are written in C and have to be compiled. While the line above is technically correct, you can use the -I switch to override the ROM file syatem (which is what that refers to) and have the initialisation files stored on disk instead.
PPD files aren't going to help you with Ghostscript, these are PostScript Printer Description files and they are used by applications which generate PostScript to customise the PostScript program for the specific printer. These are (I think) used by CUPS, but not by Ghostscript.
I think THIS is the commit to remove gdevadmp.
I think this was removed in a flurry of activity removing stuff referred to as "moribund" MacOS and classic Mac stuff, and I think this specific removal was unwarranted and unwise, as these drivers are still in use today Using foomatic-rip:
http://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=a87e380acd5e326f7d4e4380348bac393fac3058
I am another Mac User and ImageWriter and ImageWriterLQ owner, I do not speak for Artifex.
at version 9.05, the file gdevadmp containing appledmp, iwhi, and iwlo, and iwlq was MOVED into the 'devices' folder. It survived there until version 9.20.
After version 9.20 it was removed in an operation that included only gdevadmp and its supporting files. The note does not say WHY it was removed.
So a 64-bit build of ghostscript 9.20 has some potential.
The files available at:
https://wiki.linuxfoundation.org/openprinting/macosx/foomatic#ghostscript_for_mac_os_x_103x_panther_-_mac_os_x_109x_mavericks
are still good, but gs and the filters need to be moved to a directory that remains accessible after the lockdown of sandboxing (about Mavericks) Suggested directory is noted in the apple support community discussion you posted earlier.
Links on the Ghostscript web site say that THIS (StackOverflow) is the official forum for discussing issues related to Ghostscript.
If that is not appropriate, what do Artifex and Ghostscript developers suggest is the "official" forum for Ghostscript issues?
I stumbled across this thread while working on a shelter-in-place project to resurrect my ImageWriter II by building Ghostscript and cups-filters for Catalina. My solution isn’t quite there yet; I can get 75% of the CUPS printer test page printed before silently crashing.
The solution for defeating sandboxing is to compile Ghostscript with dynamic linking disabled. Otherwise, even if you move the gs executable into a sandbox blessed location, the gs process will get killed as soon as it tries to link in the drivers. From my notes:
Download Ghostscript 9.20, the last gs with the Apple dot matrix drivers: https://github.com/ArtifexSoftware/ghostpdl-downloads/releases/tag/gs920
Build Ghostscript with the drivers statically linked in (otherwise sandboxing gets you): ./configure --disable-dbus --disable-dynamic --disable-gtk --with-drivers=APPLE,PS --prefix=/usr/local/ghostscript-9.20
I have not yet tried to forward-port the iwhi drivers and such into the Ghostscript; that’s my next task, in the hope that it fixes the silent crash.
I have an R script that I run on a linux server (Debian Wheezy 7.7). This script is meant to do some computations and generate plots into PNGs. Unfortunatelly I get an error:
> savePlot("myplot", "png")
Error in savePlot("myplot", "png") :
can only copy from 'X11(type="*cairo")' devices
How do I get around this? I am only connected from Win XP with PuTTy, I don't have any X-windows set up on my XP and I don't want to bother with this - all I need is to run the script and produce the PNGs. Thanks!
You may have more luck calling the device internally:
png("plot.png")
plot(1)
dev.off()
If you don't want to bother with opening an instance of R, you could save the above script (e.g. "script.01.R") and run the following from the console:
R CMD BATCH script.01.R
This should also work to create the .png.
On my Ubuntu distribution, calling x11() before plot() resolved this issue. This blog post gives more details on different operating systems.
In my program I use something like this -
String arielunicodePath = config_Folder_Path+File.separatorChar
+"resources"+File.separatorChar + "ARIALUNI.ttf";
arielunicodebase = BaseFont.createFont(arielunicodePath, BaseFont.WINANSI, BaseFont.EMBEDDED);
I have put the ARIALUNI.ttf file in the correct location in my project.
Its working fine on my windows machine. But when i deploy it to our Linux server, the font creating command above fails with below error -
java.io.IOException: /x/programs/reporttransformationmsgd/config/resources/ARIALUNI.ttf not found as file or resource.
I confirmed that the file is available on the exact location the program is looking for.
What am I missing here?
When developing on Windows and deploying on Linux, one sometimes forgets that Linux generally handles file names in a case-sensitive manner while Windows does not.
In the case at hand the file name the program sought for was ARIALUNI.ttf while the font file actually (just like in the Windows fonts folder) was named ARIALUNI.TTF.
Testing on Windows the lower case extension meant no problem while on Linux it gave rise to the not found as file or resource IOException.
Our application runs some commands in a headless mode using frame buffer display. We can't rely on fact that Xvfb is installed on every machine, but we suppose that X server is, so we bundle Xvfb binary into our application. The problem is that on some machines, when running bundled Xvfb we get the following fatal error:
could not open default font 'fixed'
Is there a way to bundle basic fonts as well, and point Xvfb binary to them, or is there a more elegant solution to this?
Thanks!
There is a more elegant solution coming up in the future, it is called Xdummy and is the ability to use a real X11 server with the dummy driver to get a virtual screen backed by a real server (Xvfb is barely maintained nowadays). More details (and packages) here, it is based on Xdummy by Karl Runge but is much cleaner (no shared library tricks)
This will be part of Xorg server 1.12 (due shortly)
Until then, you could wrap Xvfb in a little script which figures out where the fonts are on the system (there aren't that many places) and adds the -fp string default font path argument to the command line.
Modern versions of libXfont from X.Org have the basic "fixed" and "cursor" fonts builtin, but until the more recent versions (I believe Xorg 1.7 from 2009), you needed to specify "built-ins" in the font path explicitly for Xservers like Xvfb to find them.