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
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.
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 want to (manually) insert additional postscript commands in a postscript file that was converted from a PDF file via ghostscript’s pdf2ps. For the purpose of testing I created a PDF file from the following file using pdflatex:
\documentclass[a4paper]{article}
\begin{document}
Mostly empty.
\end{document}
In the converted postscript file I make the following edit:
...
%%Page: 1 1
%%PageBoundingBox: 0 0 595 841
%%BeginPageSetup
4 0 obj
<</Type/Page/MediaBox [0 0 595.28 841.89]
/Parent 3 0 R
/Resources<</ProcSet[/PDF]
/Font 8 0 R
>>
/Contents 5 0 R
>>
endobj
%%EndPageSetup
% BEGIN MANUAL EDIT
0 setgray 0 0 moveto 595 841 lineto stroke
% END MANUAL EDIT
5 0 obj
<</Length 257>>stream
q 0.1 0 0 0.1 0 0 cm
0 G
0 g
q
10 0 0 10 0 0 cm BT
/R6 9.9626 Tf
1 0 0 1 139.746 706.129 Tm
[(M)-0.699638(os)-0.399443(t)-0.900585(l)-0.798886(y)-333.819(e)-0.400668(m)-0.300195(p)-0.599165(t)26.0974(y)83.192(.)-0.800112]TJ
154.421 -615.691 Td
(1)Tj
ET
Q
Q
endstream
endobj
pagesave restore
%%PageTrailer
%%Trailer
end
%%EOF
Instead of producing a diagonal line the postscipt/PDF file remains (seemingly) unchanged. However, if I alter the page dimensions from A4 to letter size the line is shown:
%%Page: 1 1
%%PageBoundingBox: 0 0 612 792
%%BeginPageSetup
4 0 obj
<</Type/Page/MediaBox [0 0 612 792]
...
I am obviously missing something here (which is not surprising given my rudimentary knowledge of postscript). My question is: How can I make the line appear while keeping the page dimensions unchanged?
P.S.: A comment I stumbled across mentioned that pdftops (from poppler-utils) is in some sense superior to pdf2ps. Indeed, inserting commands into the converted postscript file immediately before the showpage command (which is not there at all when using pdf2ps) worked fine. So I have probably already found a solution to my problem. However, I would like to learn what the page dimensions have to do with it when using pdf2ps.
Solution
Thanks to KenS’s advice and referring to his answer to this question I was able to achieve the desired effect by adding an EndPage procedure to the postscript file:
<<
/EndPage
{
exch pop 2 lt
{
gsave
0 0 translate
0 setgray 0 0 moveto 596 842 lineto stroke
grestore
true
}{false} ifelse
} bind
>> setpagedevice
(This assumes the page size is a4.)
PostScript is a write-only language :-)
Seriously, its a programming language. In order to understand what's going on, you need to understand the program, which in the case of the output from Ghostscript's ps2write device, is distinctly non-trivial.
The syntax is basically PDF, with a prolog program which interprets it in PostScript terms.
The program will use showpage, it does it when the procedure EndStream is executed, which is (basically) when the endobj keyword is encoutnered in a page stream. You'll see that it looks like:
ET
Q
Q
Q
endstream
endobj
%%Page: 2 2
You could place anything you like between the endstream and the endobj, but you need to be aware that the graphics state at that point is determined by whatever operations have already taken place. This can include scaling, oration, skeing, flipping the vertical axis, etc. So simply inserting some PostScript into there is unlikely to work. You could do an initgraphics which would at least reset the graphics state to a known setup.
As a test I ran Ghostscript'sd ps2write device like this:
gs -sDEVICE=pdfwrite -o out.ps -c "showpage" -f
which produces a PostScript program where the (effective) content is:
%%EndResource
%%EndProlog
%%Page: 1 1
%%PageBoundingBox: 0 0 595 842
%%BeginPageSetup
4 0 obj
<</Type/Page/MediaBox [0 0 595 842]
/Parent 3 0 R
/Resources<</ProcSet[/PDF]
>>
/Contents 5 0 R
>>
endobj
%%EndPageSetup
5 0 obj
<</Length 23>>stream
q 0.1 0 0 0.1 0 0 cm
Q
endstream
endobj
%%Trailer
end
%%EOF
I then modified this more or less as you suggested:
%%EndPageSetup
0 setgray 0 0 moveto 595 842 lineto stroke
5 0 obj
<</Length 23>>stream
q 0.1 0 0 0.1 0 0 cm
Q
endstream
endobj
%%Trailer
For me this produced the expected stroke from bottom left to top right. Obviously without the PostScript file you originally produced I can't tell you why your experience is different. (no I'm not in a position to run latex to produce such a thing, and even if I did I have no way to know which version of Ghostscript and the other tools you used).
My guess would be that 'something' in your PDF file overwrote the entire page, its not entirely uncommon.
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