Ghostscript error limitcheck in string - ghostscript

Why is the final part of my PDF creation process failing please. See output from ps2pdf command below. This is at the end of my own developed tool chain. I harvest images from Matlab, stitch them together using LaTeX and then create the final PDF using latexmk.
This has worked fine until now when the document in question has grown to 3356 pages!
File position 238282 in file output.ps (as mentioned in the ghostscript error output) is towards the end of the "SDict begin [ {Catalog} << /PageLabels<>1<>2 " line. This line is 51542 chars long and describes all 3356 pages.
Is this line length just too long now? If I trim my .tex file down towards 3000 pages and re-run the latexmk it completes fine.
Running ps2pdf in isolation to show error. Same error when run from latexmk:
C:\temp>c:\MiKTeX\miktex\bin\ps2pdf.exe output.ps output.pdf > error.txt 2>&1
Gave output:
Error: /limitcheck in --string--
Operand stack:
--nostringval-- --nostringval-- --dict:1/1(L)-- PUT --nostringval-- 2 --nostringval-- 2 false --nostringval-- --nostringval-- (]) --nostringval-- --nostringval-- (3327) --nostringval-- --nostringval-- P 1 .pdfcvstring (<<\n/P \(3225\)\n>> 3226 <<\n/P \(32) (<<\n/Nums [0 <<\n/P \(1\)\n>> 1 <<\n/P \(1\)\n>> 2 <<\n/P \(2\)\n>> 3 <<\n/P \(3\)\n>> 4 <<\n/P \(4\)\n>> 5 <<\n/P \(5\)\n>> 6 <<\n/P \(6\)\n>> 7 <<\n/P \(7\)\n>> 8 <<\n/P \(8\)\n>> 9 <<\n/P \(9\)\n>> 10 <<\n/P \(10\)\n>> 11 <<\n/P \(11\)\n>> 12 <<\n...) 65550
Execution stack:
%interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1910 1 3 %oparray_pop 1909 1 3 %oparray_pop 1893 1 3 %oparray_pop 1787 1 3 %oparray_pop --nostringval-- %errorexec_pop .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- 1917 4 5 %oparray_pop --nostringval-- 3 1 2 --nostringval-- %for_pos_int_continue --nostringval-- --nostringval-- --nostringval-- --dict:1/1(L)-- --nostringval-- 1 %dict_continue --nostringval-- --nostringval-- --nostringval-- --nostringval-- %array_continue --nostringval-- --nostringval-- --dict:1/1(L)-- --nostringval-- 1 %dict_continue --nostringval-- --nostringval-- %zwritecvp_continue 1 %s_proc_write_continue --nostringval-- --nostringval-- --nostringval-- --nostringval--
Dictionary stack:
--dict:1159/1684(ro)(G)-- --dict:0/20(G)-- --dict:81/200(L)-- --dict:188/300(L)-- --dict:36/200(L)-- --dict:10/10(G)--
Current allocation mode is local
Last OS error: No such file or directory
Current file position is 238282
MiKTeX GPL Ghostscript 9.00: Unrecoverable error, exit code 1
Edit: Added my complete page labels line from the postscript file that goes into ps2pdf. See pastebin entry http://pastebin.com/FFvZpaRY

I ran pdfmark you provided with 9.10's pdfwrite device without error, but 9.00 fails with the same message as you show.
Ghostscript has been extended to support Postscript string and array
objects with >64k entries.
Update:
Assuming, that page labels you need are 1,1,2,3...3261 (don't know why, but that's what is in your example), it's simpler to add auto-incrementing numeric labels, not string prefixes as you do.
[{Catalog}<<
/PageLabels<</Nums[0<</S/D>>1<</S/D>>]>>
>> /PUT pdfmark
Or, if prefixes are what's necessary, split your big array into two or more:
[/_objdef{leaf1}/type/dict/OBJ pdfmark
[/_objdef{leaf2}/type/dict/OBJ pdfmark
[{leaf1}<</Limits[0 3000]
/Nums[
... 0 to 3000 labels go here ...
>>/PUT pdfmark
[{leaf2}<</Limits[3001 3261]
/Nums[
... 3001 to 3261 labels go here ...
>>/PUT pdfmark
[{Catalog}<</PageLabels<</Kids[{leaf1} {leaf2}]>>
>>/PUT pdfmark
Both these solutions work with 9.00

Related

Ghostscript /stackunderflow in CMap definition

I'm trying to create a simple CMap with mapping for two CIDs. Any idea what's wrong with following CMap?
/CIDInit /ProcSet findresource begin
13 dict begin
begincmap /CIDSystemInfo <<
/Registry (Adobe) /Ordering (Identity) /Supplement 0 >> def
/CMapName /CM def
/CMapType 1 def
1 begincodespacerange
<00> <02>
endcodespacerange
2 begincidchar
<01> 6691
<02> 6692
endcidchar
endcmap CMapName currentdict /CMap defineresource
pop end end
gs interpreter throws following error:
Error: /stackunderflow in --index--
Operand stack:
1 --nostringval-- (\002) 6691 (\001) (\000\000\000\002) () (\032#) 0 (\001) 10
Execution stack:
%interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1992 1 3 %oparray_pop 1991 1 3 %oparray_pop 1979 1 3 %oparray_pop 1833 1 3 %oparray_pop --nostringval-- %errorexec_pop .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- 1 --nostringval-- %repeat_continue --nostringval-- --nostringval--
Dictionary stack:
--dict:730/1123(ro)(G)-- --dict:0/20(G)-- --dict:75/200(L)-- --dict:38/38(ro)(G)-- --dict:8/13(L)--
Current allocation mode is local
Current file position is 270
GPL Ghostscript 9.27: Unrecoverable error, exit code 1
This was a bug which is fixed now.
For individual code mappings (endnotdefchar/endcidchar) we check if the
previous mapping values are adjacent to the current one, so we can optimize by
merging them into a range. Each map involves 5 entries on the stack, and the
check to trigger the attempt to merge checked for >5 entries on the stack. That
works as long as the number of mappings is large enough that we always have at
least 10 entries (the merging code will cope with unprocessed entries).
In this case, we only have two mappings, when we reach the check for a marge
condidate, there are seven entries on the stack (5 for the current, 2 for the
remaining mapping), and we end up with a stackunderflow error, because code
expects at least 10 objects on the stack.
Thanks #chrisl

What could cause a colored mac app icon to be displayed as grayscale?

Note: MCVE at the end
I updated the AppIcon and Document icon for my mac app. The icons have changed but they also show as grayscale. The sources files (PNGs) are colored. The icons appear colored inside Xcode but in context (AppIcon in the dock and Document icons in Finder) are grayscale. I've tried the obvious stuff like cleaning the build folder, relaunching Xcode and relaunching Finder but I don't know what else to try.
This is how the icons appear in context:
This is how the icons appear in Xcode:
All I did was update some PNGs! Everything still functions correctly. The app still launches and double clicking on a document opens the application. The problem is that the icons are gray.
In the git commit that changes the icons, the only things that change are some PNGs and a few documentation files (a link in the README, a screenshot and some other stuff). If I checkout the commit before changing the icons, everything is fine. If I checkout the commit that changes the icons, they're gray.
I've been looking at the PNGs themselves to try to figure this out. I'm using pngcheck to inspect the files.
Old (working) 16x16 icon:
chunk IHDR at offset 0x0000c, length 13
16 x 16 image, 32-bit RGB+alpha, non-interlaced
chunk bKGD at offset 0x00025, length 6
red = 0x00ff, green = 0x00ff, blue = 0x00ff
chunk IDAT at offset 0x00037, length 142
zlib: deflated, 2K window, maximum compression
row filters (0 none, 1 sub, 2 up, 3 avg, 4 paeth):
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 (16 out of 16)
chunk IEND at offset 0x000d1, length 0
New (broken) 16x16 icon:
chunk IHDR at offset 0x0000c, length 13
16 x 16 image, 32-bit RGB+alpha, non-interlaced
chunk IDAT at offset 0x00025, length 109
zlib: deflated, 2K window, default compression
row filters (0 none, 1 sub, 2 up, 3 avg, 4 paeth):
0 1 1 1 2 2 4 1 1 4 2 2 1 1 0 0 (16 out of 16)
chunk IEND at offset 0x0009e, length 0
Ok, so maybe the bKGD chunk is required? Nope. I passed the image through gm convert (with no arguments) which adds the bKGD and also changes the compression level and it's still being displayed in grayscale.
New (broken) 16x16 icon after gm convert:
chunk IHDR at offset 0x0000c, length 13
16 x 16 image, 32-bit RGB+alpha, non-interlaced
chunk bKGD at offset 0x00025, length 6
red = 0x00ff, green = 0x00ff, blue = 0x00ff
chunk IDAT at offset 0x00037, length 106
zlib: deflated, 2K window, maximum compression
row filters (0 none, 1 sub, 2 up, 3 avg, 4 paeth):
0 1 1 1 2 2 4 1 1 4 2 2 1 1 0 0 (16 out of 16)
chunk IEND at offset 0x000ad, length 0
So now it looks like the only difference between the broken PNGs and the working ones are the row filters (and of course the image data itself). WHY ON EARTH WOULD THIS CAUSE A PROBLEM?! I'm not aware of a way to set the row filters using the command line alone. Is this even possible to do with libpng? Whenever I use libpng, I just let the library choose the filters. Would I have to write my own png encoder to solve this?
I feel like I must be barking up the wrong tree here but the only thing that changed (that affects the build) are a handful of PNG files. This is insane.
I played around with this some more and found that the 128#2x icon (not the 256 icon!) is the one that matters. Replacing this image with the old icon causes the old icon to be shown in color. Replacing this image with the new icon cases the new icon to be shown in grayscale. The difference between these two PNG files is what's causing the issue. This is the most ridiculous problem that I've ever encountered.
I'm trying to bring these images closer together to try to make the new one work or the old one break but I just can't figure it out. I passed the old image through the same tool that I used to make the new image (which happens to be the application for which this icon is for!) AND IT STILL SHOWS UP IN COLOR! Here's the pngcheck output.
Old (working) 128x128#2x icon after animera:
chunk IHDR at offset 0x0000c, length 13
256 x 256 image, 32-bit RGB+alpha, non-interlaced
chunk IDAT at offset 0x00025, length 965
zlib: deflated, 32K window, default compression
row filters (0 none, 1 sub, 2 up, 3 avg, 4 paeth):
1 2 2 2 2 2 2 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1
2 2 2 2 2 2 2 1 2 2 2 2 2 2 2 1 2 2 2 2 2 2 2 1 2
2 2 2 2 2 2 2 2 2 2 2 2 2 2 1 2 2 2 2 2 2 2 2 2 2
2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 4 2 2 2
2 2 2 2 1 2 2 2 2 2 2 2 1 2 2 2 2 2 2 2 1 2 2 2 2
2 2 2 4 2 2 2 2 2 2 2 1 2 2 2 2 2 2 2 4 2 2 2 2 2
2 2 4 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
2 2 2 2 2 2 2 2 2 1 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
1 2 2 2 2 2 2 2 1 2 2 2 2 2 2 2 1 2 2 2 2 2 2 2 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 (256 out of 256)
chunk IEND at offset 0x003f6, length 0
New (broken) 128x128#2x icon after animera:
chunk IHDR at offset 0x0000c, length 13
256 x 256 image, 32-bit RGB+alpha, non-interlaced
chunk IDAT at offset 0x00025, length 830
zlib: deflated, 32K window, default compression
row filters (0 none, 1 sub, 2 up, 3 avg, 4 paeth):
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 2 2 2 2 2 2 2 2
2 2 2 2 2 2 2 1 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 1 2
2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 4 2 2 2
2 2 2 2 2 2 2 2 2 2 2 2 1 2 2 2 2 2 2 2 2 2 2 2 2
2 2 2 1 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 4 2 2 2 2 2
2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 1 2 2 2 2 2 2 2
2 2 2 2 2 2 2 2 1 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 (256 out of 256)
chunk IEND at offset 0x0036f, length 0
This is ridiculous! I'm beginning to wonder if I've found a very strange bug in macOS.
In case you want to inspect the images yourself, these are the two images from the previous section. I think imgur re-encodes images so I converted them to data URIs so you can paste them into the URL bar and download them.
Old (working) 128x128#2x icon after animera:
data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAQAAAAEACAYAAABccqhmAAADxUlEQVR4nO3dQW6kMBRAQRjl/ldmbgALx7KdV7XNIg7debL0DdzPdd3Xi/u6nrefA+f6t3oBwDoCAGECAGECAGECAGECAGECAAAAAAAAAAAAAAAAAAAAAAAbeX0nAOs9h7+X4fYd25onAkGYAECYAECYAECYAECYAECYAECYGe1kp8/xV3OOYC47AAgTAAgTAAgTAAgTAAgTAAgTAAgzYx1kzr+WcwJj7AAgTAAgTAAgTAAgTAAgTAAgTAAgzAz1gzn/2ZwTeGcHAGECAGECAGECAGECAGECAGECAGECAGECAGECAGECAGECAGECAGECAGECAGH5e6Xd799Wf16AHQCECQCECQCECQCECQCECQCECQCECQCECQCECQCECQCECQCECQCECQCECQCECQCECQCECQCECQCECQCECQCECQCECQCECQCECQCECQCECQCECQCECQCECQCECQCE/axewHTP9axewpDj316//eX/WOB9/Cfwxg4AwgQAwgQAwgQAwgQAwgQAwgQAwvafcU6e428/pR41/An/7Ss0/x9g73MEdgAQJgAQJgAQJgAQJgAQJgAQJgAQtn5Gufn9+lsv7jfcf/svXP8F/7L2nIAdAIQJAIQJAIQJAIQJAIQJAIQJAITNn0FuPuf/cvTir+sa/gv2H6S/Onz51+xzAnYAECYAECYAECYAECYAECYAECYAEPazegG7+xrCnn9O4Gznz/nXsgOAMAGAMAGAMAGAMAGAMAGAMAGAsPEx6uH3+882/+IsvvyTB/Hm/F/GnhdgBwBhAgBhAgBhAgBhAgBhAgBhAgBhngcw2egc+/RDFub4e7MDgDABgDABgDABgDABgDABgDABgDDnADZnjs5MdgAQJgAQJgAQJgAQJgAQJgAQJgAQJgAQJgAQJgAQJgAQJgAQJgAQJgAQJgAQJgAQJgAQJgAQJgAQJgAQJgAQJgAQJgAQJgAQJgAQJgAQJgAQJgAQJgAQJgAQJgAQNv/188/1TP8dvBi8/PO/Iby6p34CdgAQJgAQJgAQJgAQJgAQJgAQJgAQJgAQJgAQJgAQJgAQJgAQJgAQJgAQJgAQtv5ub88LWOt2+deae7//FzsACBMACBMACBMACBMACBMACBMACFt/DuCLcwJj7tHP+HH9h6yd83+xA4AwAYAwAYAwAYAwAYAwAYAwAYCwrWeUv+L0cwTDc/zVTj9HsPccf5QdAIQJAIQJAIQJAIQJAIQJAIQJAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAvPgPQZExnSU6E9oAAAAASUVORK5CYII=
New (broken) 128x128#2x icon after animera:
data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAQAAAAEACAYAAABccqhmAAADPklEQVR4nO3cwZEDIQwAQbhy/injDO7DQ6amOwJ5dz3FR6wFAAAAAAAAAAAAAAAAAAAA/Jo9PUDdWetMzzBp+wZH/U0PAMwRAAgTAAgTAAgTAAgTAAgTAAgTAAgTAAgTAAgTAAgTAAgTAAgTAAgTAAizi32pvs8/zX0Cd5wAIEwAIEwAIEwAIEwAIEwAIEwAIEwAIEwAIEwAIEwAIEwAIEwAIEwAIEwAICy/S22fv61+n4ATAIQJAIQJAIQJAIQJAIQJAIQJAIQJAIQJAIQJAIQJAIQJAIQJAIQJAIQJAIQJAIQJAIQJAIQJAIQJAIQJAIQJAIQJAIQJAIQJAIQJAIQJAIQJAIQJAIQJAIQJAIQJAIQJAIQJAIQJAIQJAIQJAIQJAIQJAIQJAIQJAIQJAIQJAIQJAIQJAIQJAIQJAIR9pge4dtaZHmHUnh7g+cd/+QP2+Bu44QQAYQIAYQIAYQIAYQIAYQIAYQIAYQIAYQIAYQIAYQIAYQIAYQIAYQIAYQIAYfO7zI/v8z89/Fpr7bd/wfwHfGv2PgEnAAgTAAgTAAgTAAgTAAgTAAgTAAgTAAgTAAgTAAgTAAgTAAgTAAgTAAgTAAi730V+fJ9/2v3DG378l1/Q+/v80+7uE3ACgDABgDABgDABgDABgDABgDABgDABgDABgDABgDABgDABgDABgDABgDABgLDP9AB19uGZ5AQAYQIAYQIAYQIAYQIAYQIAYQIAYQIAYQIAYQIAYQIAYQIAYQIAYQIAYQIAYQIAYQIAYQIAYQIAYQIAYQIAYQIAYQIAYQIAYQIAYQIAYQIAYQIAYQIAYQIAYQIAYQIAYQIAYQIAYQIAYQIAYQIAYQIAYQIAYQIAYQIAYQIAYQIAYQIAYQIAYQIAYQIAYXt6gHXWmR4hbXv8s/bof9AJAMIEAMIEAMIEAMIEAMIEAMIEAMIEAMIEAMIEAMIEAMIEAMIEAMIEAMIEAMLm7wO4Vb9PYE+/w9N+/sP7/LecACBMACBMACBMACBMACBMACBMACBMACBMACBMACBMACBMACBMACBMACBMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4B9fjX8anopwslQAAAAASUVORK5CYII=
I really hope someone can figure this out!
I have created a MCVE of this problem (on github). I created a new mac app. All I did was set the 128#2x icon and I'm able to reproduce this problem. The "working" icon is in color. The "broken" icon is gray (see the data URIs from the previous section). You can edit the filename in the Contents.json file (followed by a clean build) to switch between them. It's beginning to seem like I've found a bug in macOS! Although, if it is a bug then it probably won't be fixed in Mojave.
I sent a bug report to Apple. I would still like a workaround for this as I haven't been able to find one.
The problem can be reproduced on macOS Catalina with Xcode 11.3.1.
Narrowing down the problem
The asset catalog (.xcassets) is compiled by Xcode to an Asset.car file.
To take a look into the compiled Asset.car and even extract an image resource from it, you would need an additional tool, e.g. the Asset Catalog Tinkerer.
Installation of this tool can be achieved by:
brew cask install asset-catalog-tinkerer
With the tool the image can be extracted from the Asset.car. It's named 256_broken_Normal#2x.png and it is a grayscale image.
One can check this visually or with the command line call:
sips -g all 256_broken_Normal#2x.png
The output of the tool is:
/Users/stephan/tmp/256_broken_Normal#2x.png
pixelWidth: 256
pixelHeight: 256
typeIdentifier: public.png
format: png
formatOptions: default
dpiWidth: 72.000
dpiHeight: 72.000
samplesPerPixel: 2
bitsPerSample: 8
hasAlpha: yes
space: Gray
profile: Generic Gray Gamma 2.2 Profile
So you can see that it is no longer RGBA32 but a grayscale image with alpha channel (see samplesPerPixel, hasAlpha and color space properties).
First Result
So this probably isn't a bug in macOS, but rather the creation of the Asset.car file.
Content Analysis I
Interestingly, you can't fix the problem by removing and re-adding color profiles, nor by loading the image into an image processor and rewriting it.
So could it be the pixel content values of the image?
Next try: change a single pixel in the red area of the image editing software from #0xff0000ff to #0xff0100ff. So this is a change that the human eye should not be able to see visually, but in this case you can see it: the image is no longer grayscale, but colored.
Let's analyze the colors further and interessting: each value in the 4 channels has either the value 0x00 or 0xff which gives 16 different combinations.
Create Random Image
That sounds like a lead. So next try: Create a small program that randomly uses one of the 8 possible opaque colors (all combinations of 0x00 or 0xff per rgb channel, alpha = 0xff).
The outcome is a color image.
Content Analysis II
Let's look at the picture again. Could it be that the colors are evenly distributed?
Now let us analyze with a small program that counts how often the R G B A values 0xff occur, the result is:
R G B A
212992 212992 212992 540672
It is indeed the case that the R, G and B with the value 0xff occur in exactly the same number.
Hypothesis
To further substantiate this hypothesis, one can now programmatically generate a stripe pattern in which the colors occur equally often.
And indeed, with this image we see a grayscale image in the Dock and in the App Switcher, see in the screenshot the assets in the background and the grayscale app icon when using the App Switcher via CMD+TAB in the foreground.
Now we make another attempt with a semi-random distribution of small squares of the same color. And again, when using that image in Xcode we get a grayscale app icon, see screenshot.
Test
Whenever changing the image, the first thing you have to do in Xcode is a <Product/Clean Build Folder> (SHIFT-CMD-K).
If one would like to test that on your own, here are the images:
https://www.software7.biz/iertzzlmbkjdkjrk/256_randomWorking.png (working -> color)
https://www.software7.biz/iertzzlmbkjdkjrk/256_brokenStripes.png (broken -> grayscale)
https://www.software7.biz/iertzzlmbkjdkjrk/256_semiRandomBroken.png (borken -> grayscale)
Summary
So it doesn't seem to be a bug in macOS, but during compilation/optimization of the assets into the Asset.car file. It seems to happen when the number of R,G,B values equal to 0xff is the same. There may be other cases.
A simple workaround seems to be to simply change the value of one pixel very slightly. This cannot be seen by the human eye.

Is the second of these solutions more efficient?

Wondering if as a practical matter the post-compilation of the second solution below is more efficient .
first solution :
write_data([]).
write_data([_]) :-
write('LAST!'),nl.
write_data([X|Rest]) :-
Rest = [_|_],
write(X),nl,
write_data(Rest).
second solution :
write_data([]).
write_data([H|T]) :-
write_data(T, H).
write_data([], _) :-
write('LAST!'),nl.
write_data([H|T], X) :-
write(X),nl,
write_data(T, H).
some swipl magic :
?- [library(vm)] .
?- vm_list(write_data) , halt.
first solution swipl magic ::
========================================================================
write_data/1
========================================================================
0 s_virgin
1 i_exit
----------------------------------------
clause 1 (<clause>(0xb002c300)):
----------------------------------------
0 h_nil
1 i_exitfact
----------------------------------------
clause 2 (<clause>(0xb017da50)):
----------------------------------------
0 h_list
1 h_void
2 h_nil
3 h_pop
4 i_enter
5 b_atom('LAST!')
7 i_call(write/1)
9 i_depart(nl/0)
11 i_exit
----------------------------------------
clause 3 (<clause>(0xb002bc80)):
----------------------------------------
0 h_list_ff(1,2)
3 i_enter
4 b_unify_var(2)
6 h_list
7 h_pop
8 b_unify_exit
9 b_var1
10 i_call(write/1)
12 i_call(nl/0)
14 b_var2
15 i_depart(write_data/1)
17 i_exit
second solution swipl magic ::
========================================================================
write_data/1
========================================================================
0 s_virgin
1 i_exit
----------------------------------------
clause 1 (<clause>(0xb272c300)):
----------------------------------------
0 h_nil
1 i_exitfact
----------------------------------------
clause 2 (<clause>(0xb27288c0)):
----------------------------------------
0 h_list_ff(1,2)
3 i_enter
4 b_var2
5 b_var1
6 i_depart(write_data/2)
8 i_exit
========================================================================
write_data/2
========================================================================
0 s_virgin
1 i_exit
----------------------------------------
clause 1 (<clause>(0xb2728920)):
----------------------------------------
0 h_nil
1 i_enter
2 b_atom('LAST!')
4 i_call(write/1)
6 i_depart(nl/0)
8 i_exit
----------------------------------------
clause 2 (<clause>(0xb272bc80)):
----------------------------------------
0 h_list_ff(2,3)
3 i_enter
4 b_var1
5 i_call(write/1)
7 i_call(nl/0)
9 b_var(3)
11 b_var2
12 i_depart(write_data/2)
14 i_exit
Upon submission of the above stack overflow blocked with message "It looks like your post is mostly code; please add some more details." . HRM . Too much code in a question about computer programming ? (skratches virtual head) . Should I add some verbiage I heard about the new revolution "Bunch-Oriented" programming whilst around the water-cooler ?

I can't find a pattern of this 6*6 matrix

It's a kind of programming practice problem.
The question is, "Print this matrix".
0 1 2 3 4 5
1 2 3 4 5 0
0 1 2 3 0 1
5 0 5 4 1 2
4 5 4 3 2 3
3 2 1 0 5 4
=========================
Well, I can use 'printf' for 16 times, but I don't wanna do that.
There would be some pattern..
But really, I couldn't figure it out. I struggled with it for a week..!
It is a clockwise spiral starting at the top left.

error in conversion of raster file to postscript file

I am trying to convert PWG raster file data into postscript data. I have generated at test file which is as follows:
%!PS-Adobe-3.0
%%BoundingBox: 0 0 5100 6600
%Creator: Cups-Filters
%LanguageLevel: 2
%DocumentData: Clean7Bit
%EndComments
%BeginProlog
%EndProlog
%Pages: (atend)
%%Page: 1 1
%%BeginPageSetup
<< /PageSize[5100 6600]/ImagingBBox null>> setpagedevice
%%EndPageSetup
gsave
gsave
5100 6600 scale
5100 6600 8 [5100 0 0 -6600 0 6600]
{currentfile 3 5100 string readhexstring pop} bind
false 3 colorimage
...hexadecimal information cut...
grestore
showpage
%PageTrailer
%Trailer
%%Pages: 1
%EOF
Whenever I try to run the program using GhostScript interpretor, I get the following error:
$ ghostscript sample.ps
GPL Ghostscript 9.18 (2015-10-05)
Copyright (C) 2015 Artifex Software, Inc. All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
Error: /typecheck in --colorimage--
Operand stack:
--nostringval-- 3 (\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000...)
Execution stack:
%interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1977 1 3 %oparray_pop 1976 1 3 %oparray_pop 1960 1 3 %oparray_pop 1852 1 3 %oparray_pop --nostringval-- %errorexec_pop .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- 1878 7 3 %oparray_pop
Dictionary stack:
--dict:1194/1684(ro)(G)-- --dict:0/20(G)-- --dict:78/200(L)--
Current allocation mode is local
Current file position is 399
GPL Ghostscript 9.18: Unrecoverable error, exit code 1
The PS file is about 128 MB with about 99% data being the hexadecimal representation of the coloured image.
I tried searching it and one source suggested to add 'setpagedevice' parameter to the PS file. I have added it but to no effect.
How can I get rid of this error ? Also, is there any other way to represent very large images in postscript ?
Your code contains:
{currentfile 3 5100 string readhexstring pop} bind
If we break that up and add comments about the stack content we get:
{
currentfile % Stack contents: -file-
3 % stack contents: -file- 3
5100 % stack contents: -file- 3 5100
string % string consumes the top operand, creates a string
% object of that size, and places the string on the stack
% stack contains: -file- 3 (string)
readhexstring % consume string and file operands, return substring, bool
%
pop % pop the boolean
}
The problem is that readhexstring expects to see -file- (string) but the stack actually contains 3 (string), 3 isn't a file object so you get a typecheck error.

Resources