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.
Related
My old FOSS project
https://akrobiz.com/ezfb/
used to compile just fine, but that was in 2016.
Now I get multiple function definitions in the linker.
I realize I have to also add -lm to the link command for the math.
To run the demos, you need a frame buffer enabled kernel.
To compile you need fb.h.
It's good to have fbset installed and have a display device that is not running X.
TIA!
James.
http://community.activestate.com/node/7011
It's kinda like that poor chap shang (can I use chap gender-neutrally?) over there in the link, except it's another year and I have MSVS 2012.
Details
CMake has placed C:...\Tcl\lib\tcl85.lib on the dependencies list for my binary (I checked in the generated .vcproj file - it's there). Nevertheless, the linker errors are numerous and of the form:
nativeTCL_wrap.obj : error LNK2019: unresolved external symbol __imp__Tcl_[some-command-name] referenced in function _SWIG_Tcl_[some-other-command-name].
So I check the header file as listed in the dependencies list for my project in MSVS: version is #define as 8.5. This matches the library that I'm trying to link to. I tried exploring tcl85.lib with dependency walker. Apparently it can't explore that kind of file. I ran dumpbin.exe on it... And the .lib file has ALL OF THE MISSING FUNCTIONS, but of the following form:
__imp_Tcl_[some-command-name]
It has all of the symbols... But there's an underscore missing in each of them!
I then explored the libtcl85.dll.a file given by ActiveState's Tcl distro used in Cygwin, and the symbols look like this:
__imp__Tcl_[some-command-name]
So it has the extra underscore, and the binary links properly on Cygwin.
...
This is seriously one of those moments where I'm throwing my hands up in the air and thinking, "What do?" in all of its simplistic grammatically screwed up glory. The same swig interface file with the same CMake generates a module successfully in Cygwin. But developing Cygwin is a pain in the ass because of how slow it is (builds are almost 5-8 times as long as in more native-Windows-ish systems).
What Happens Next?
Do I try to convince Swig to generate with dependencies with one less underscore? If so how? Do I give up and file a bug report? If so, where? Is this a bug in ActiveState Tcl? Is this a bug in Swig? Is this not a bug at all and I'm just screwed?
For the lack of an underscore the kingdom was lost?
So, as I was writing my question, I started thinking about all of the different alternatives to how this could have gone wrong. Then I remembered that CMake by default chooses the 32-bit version of MSVS. I am now feeling quite sheepish, but as someone else apparently had a similar problem on the ActiveState fora, I'm leaving my answer here for anyone else needing this little, tiny, itsy bitsy reminder...
As it turned out, selecting the 64-bit version of MSVS with cmake -G "Visual Studio 2012 Win64" fixed everything. Linking worked fine. The binary got loaded successfully into Tclsh.
I would've expected a more comprehensive error message from my build tool about trying to link 32-bit and 64-bit binaries together, though...
I followed the steps from skia site for compiling skia r1236 on my Ubuntu 12.04 64 bit machine.
When i run the tests , no window comes up to show the graphical result.The output on console is :
[1/33] PDFPrimitives...
...................
[33/33] BitmapCopy...
Finished 33 tests, 0 failures.
If i put a Bitmap to a file using SkImageEncoder::EncodeFile , i do get graphical output on the file. This confirms that the library is working fine but is not able to invoke linux window system.
Another problem is that while running text , i get following error
SkFontHost::OpenStream failed opening 1
--- no context for glyph 0
I have installed all freetype libraries as described by the Skia website , but still have error whichever path i use in SK_FONT_FILE_PREFIX.
My "/usr/share/fonts/" folder have
cmap
truetype
type1
X11
I noticed there is a file SkOSWIndow_Unix.cpp but nobody seems to be calling it from the test code.So my question is
1) How do we get the output to be shown on a window?
2) WHat should be the value of SK_FONT_FILE_PREFIX?
PS : The Windows port worked fine
Skia r1236 is at least two years old; you should be using something newer. The directions on the website are less than a year old.
The Linux tests and the Windows tests produce the same thing. You should see the same result from Linux as you did from Windows.
Part of the question is which particular tests you are running. From your description of the Linux shell output, these were the "gm" tests, which do not display windows. They draw pictures onto off-screen canvases.
With the "-w " option, gm will write the images as pngs into a directory.
With the "-r " option, gm will read images from a directory and compare them to the images it generates.
The SampleApp application in Skia does use the Linux window system. However, we do not support the "views" library that was used to create it. Skia is a platform-independent rendering engine; you'll need to provide your own windows management.
Note that gm functions a bit differently since somtime in the 6000s or 7000s; a default checkout will no longer contain the reference images for all GMs on all platforms.
I write project where I need to identify certain file formats.
For some formats I have found signatures that I use for identifying easily (mp3, ogg), with another formats I have a big problem (like MPEG ADTS) - I just cannot find what kind of signature can be used for it.
I found out that File utility for Linux environment can do it.
I tried to search it in source code, but I've found nothing.
I found that file utility holds its database in magic.mgc file. But it's hold in binary form.
It looks like:
Does someone perhaps know how to find that database in plain text format?
That utility isn't a Linux-specific utility; it's the version of the UN*X file command originally written by Ian Darwin. The binary .mgc file is generated from a bunch of source files.
Your Linux distribution probably has a source code package for it; where you get that package, and how you install it, depends on which distribution you're using.
The source files from which the .mgc file was generated might also be available on your distribution without installing the source package for file; if so, you could use the file command to generate it, using the -C flag. I don't see them anywhere obvious on my Ubuntu 12.04 virtual machine, so that might require some other package to be installed (file itself is installed). (On OS X, they're in the directory /usr/share/file/magic.)
Alternatively, you could download the standard version of that file (which might have been modified by your distribution, so you might not want that version) and modify and build it.
Note that, on some versions of UN*X systems, the bulk of the work done by the file command is done in library routines in the "libmagic" library; see whether your distribution has that or can install it (try, for example, man libmagic) and whether it can do the job for you.
Due to a number of constraints that I won't get into, I have to create a self-extracting ZIP archive on a linux box. The resulting archive should be executable on Windows only. Is this at all possible? If so, what tools would do the job?
Background: when the user downloads a setup package from my linux box, I need that setup package to be pre-populated with a certain key. I only know that key at runtime; my idea was to write a simple .xml file with that key, then zip up the .msi installer with that xml file into a self-extracting archive, and send that file to the browser. If you have alternative ideas on how to make it happen, I'd love to hear those, too
Your answer can be found at the following page: http://ubuntuforums.org/showthread.php?t=847329 Please note that I do not take credit for anything other than using Google and finding something that sounds logically like it would work. I do not guarantee that this information will work, or that you will be able to find the mentioned materials online anymore. I'm just a fan of Google. I hope this helps.
The problem A few days back I had to
create a Win32 compatible
self-extracting ZIP file for a friend.
Sounds easy, right. The problem was
that I didn't have a Windows machine
nearby and I didn't want to install
any archiving programs under Wine.
NOTE: A freeware ZIP program such as
IZArc under Wine can be used to create
a Win32 self-extracting ZIP file too.
That will not be covered by this
howto, sorry.
The "research" Googling around I found
this forum post dated August 2003.
Reading it I found out that
self-extracting ZIP files are nothing
more but a suitable unzip binary
followed by a normal ZIP file. I used
the unzipsfx.exe included in Info-ZIP
UnZip 5.52.
The link on that post worked a few
days ago so I got my hands on the
unzipsfx.exe that I was looking for.
Today, 2nd July 2008 I found the link
dead. After some googling I didn't
find a working link anywhere. I read
the licence a few times and understood
that I can redistribute the original
unzipsfx.exe with a license included.
Please note that the
unzipsfx-552_win32.tar.gz (80 kB) is
not an official Info-ZIP package and
it includes copyrighted software that
I take no credit for. More info in the
Info-ZIP license that is also included
in the tarball. The source code for
the binaries included can be found
here.
The solution
Step one, getting the unzipsfx.exe and
zip package:
* open the Terminal (in Ubuntu press alt+f2 and type gnome-terminal)
* type in the following commands Code:
wget
http://kolmoskone.homelinux.org/~kaja/kamaa/unzipsfx-552_win32.tar.gz
tar zxf unzipsfx-552_win32.tar.gz sudo
apt-get install zip
Step two, creating a ZIP file in
Ubuntu:
* open the file manager (nautilus) and select the files you want to have
zipped
* right click and select Create an archive (or similar). Select a
location for the ZIP file, using your
home directory is the easiest. Select
type .zip. See man zip for information
on how to create a ZIP file in command
line.
Step three, making the ZIP file
self-extracting
* type in the following commands Code:
cat unzipsfx-552_win32/unzipsfx.exe
MYZIPFILE.zip > mysfxfile.exe zip -A
mysfxfile.exe
mysfxfile.exe can now be opened in any
Win32 compatible system (including for
example Windows XP/2000/Vista and even
Wine in Linux) or ANY ZIP COMPATIBLE
archive program such as file-roller in
Ubuntu.
I was able to make this work with unzipsfx. There's a newer version of it available - just came out in April 2009 - version 6.0. Version 5.52 didn't support the critical functionality that I needed - launching a particular setup file after the extraction is completed.
So I downloaded the source files for 6.0. I then modified them to exclude the "prompt to launch stuff" check that is there by default. I recompiled using Visual Studio 2008, tried the steps described in the tutorial above, and it all works like a charm now.