michaelrsweet / rasterview Goto Github PK

Rasterview currently does not show anything when opening a PWG file on Big Sur. Is this a known issue?

For supporting multi-page documents such as the PWG's sample PWG Raster documents, some of which have multiple pages, it would be good to have controls that allow one to navigate the document: "next page" / "previous page", perhaps a text box showing the current page that is editable so that the user can enter a value to go directly to the page, total number of pages.

pdftoraster)
...
$basedir/testprint.jpg
...

Should be:

pdftoraster)
...
$basedir/testprint.pdf
...

If you do a Get Info in the Finder on RasterView.app version 1.7.1, it says the version is 1.6. Here's from the Info.plist:

<key>CFBundleVersion</key>
<string>1.6</string>

<key>CFBundleDevelopmentRegion</key>
<string>English</string>

<key>NSHumanReadableCopyright</key>
<string>Copyright © 2002-2018 by Michael R Sweet</string>

<key>CFAppleHelpAnchor</key>
<string>help</string>

<key>CFBundleName</key>
<string>RasterView</string>

<key>CFBundlePackageType</key>
<string>APPL</string>

<key>CFBundleSignature</key>
<string>CUPS</string>

<key>CFBundleIconFile</key>
<string>rasterview.icns</string>

<key>CFBundleShortVersionString</key>
<string>1.6</string>

<key>CFBundleGetInfoString</key>
<string>1.6, Copyright © 2002-2018 by Michael R Sweet</string>

I am using rasterview 1.7.1 from the Snap and if I create a CUPS Raster file with 1200 dpi and A4 page size no page image appears and a pop-up message telling that the pixel dimensions exceed a limit. The header data in the pull-out part on the right is correct, but one cannot advance to the second page of the document. Probably there is a fixed-size buffer to hold the raster data which is too small for said page size and resolution and so the page does not get fully read, meaning that the next page's header is not accessible.

The "Apple Raster" format uses the .urf file extension by default when printing through an "ippserver" IPP Printer. Yet RasterView 1.5 doesn't include that extension by default in its open dialog. That extension should be added.

The current macOS DMG is built against a version of FLTK that is using the shared PNG library. Need to re-compile without that dependency...

Open two raster files on macOS. If you do CMD+R it only ever reloads the last file opened, and if you close that file then you get an error (like it is trying to re-open the closed window's file).

Clicking in an image seems to pick an adjacent pixel's colors, at least on macOS.

Would it be unreasonable to ask for support of opening + viewing of such .gz-compressed raster files as are provided within the istopwg/ippsampe/examples/ directory?

Currently it is required to uncompress these first before even being able to even browse and detect them from the "open file" dialog of RasterView.

Version: 1.3
Original reporter: Laurent Martelli

You should #include <string.h> in main.cxx :

laurent@nicephore:~/src/rasterview-1.3$ make
g++ -D_THREAD_SAFE -D_REENTRANT -DPACKAGE_NAME="" -DPACKAGE_TARNAME="" -DPACKAGE_VERSION="" -DPACKAGE_STRING="" -DPACKAGE_BUGREPORT="" -DVERSION="rasterview\ v1.3" -c RasterDisplay.cxx
g++ -D_THREAD_SAFE -D_REENTRANT -DPACKAGE_NAME="" -DPACKAGE_TARNAME="" -DPACKAGE_VERSION="" -DPACKAGE_STRING="" -DPACKAGE_BUGREPORT="" -DVERSION="rasterview\ v1.3" -c RasterView.cxx
RasterView.cxx: In static member function �static RasterView* RasterView::open_file(const char*)�:
RasterView.cxx:704:13: warning: deprecated conversion from string constant to �char*� [-Wwrite-strings]
gcc -Wall -Wunused -Wno-char-subscripts -Wno-format-y2k -Wshadow -Winline -DPACKAGE_NAME="" -DPACKAGE_TARNAME="" -DPACKAGE_VERSION="" -DPACKAGE_STRING="" -DPACKAGE_BUGREPORT="" -DVERSION="rasterview\ v1.3" -c error.c
error.c: In function �_cupsRasterAddError�:
error.c:74:3: warning: implicit declaration of function �vsnprintf� [-Wimplicit-function-declaration]
gcc -Wall -Wunused -Wno-char-subscripts -Wno-format-y2k -Wshadow -Winline -DPACKAGE_NAME="" -DPACKAGE_TARNAME="" -DPACKAGE_VERSION="" -DPACKAGE_STRING="" -DPACKAGE_BUGREPORT="" -DVERSION="rasterview\ v1.3" -c raster.c
raster.c: In function �cupsRasterOpenIO�:
raster.c:253:11: warning: implicit declaration of function �htonl� [-Wimplicit-function-declaration]
g++ -D_THREAD_SAFE -D_REENTRANT -DPACKAGE_NAME="" -DPACKAGE_TARNAME="" -DPACKAGE_VERSION="" -DPACKAGE_STRING="" -DPACKAGE_BUGREPORT="" -DVERSION="rasterview\ v1.3" -c main.cxx
main.cxx: In function �int main(int, char**)�:
main.cxx:46:36: error: �strncmp� was not declared in this scope
make: *** [main.o] Erreur 1

I have a QHD screen (2560x1440) and many users have even higher (4K and more) screen resolution.
The GUI of rasterview seems to use a hard-coded pixel count (or DPI) for menu font sizes, buttons, ... So these GUI elements get tiny on high-resolution screens.
Can this get fixed by using the actual DPI of the screen? Many GUIs, like GTK for example, do this and so one has useful GUI element sizes on any screen resolution.

The repo description mentions Windows but is there any reason to think that it can be compiled and used on Windows? The source doesn't really look like it. :-)

When trying to compile rasterview 1.5 it chokes on "strlcpy" in raster.c.
After discovering that your intention in 1.4.1 was to replace all "strlcpy" by "strncpy" I did
perl -p -i -e 's/strlcpy/strncpy/g' .[ch]
and all worked perfectly. Can you fix that? Thanks.