What steps will reproduce the problem?
1. make, make install
2. itp
3. ctrl-C

What is the expected output? What do you see instead?

Under the executive, it should abort the current computation, print an error 
message, and resume with a PS> prompt.

Please use labels and text to provide additional information.

What steps will reproduce the problem?
1. opening website
2.
3.

What is the expected output? What do you see instead?

Mail or contact to author.

What version of the product are you using? On what operating system?

All up to the issue.

Please provide any additional information below.

Hey, contact me - I'm doing a postscript interpreter in Lua at the moment. I'm 
about as far as you probably - while I do have other preferences to do first.

-Helmar helmwo at gmail dot com

What steps will reproduce the problem?
1. make, make install
2. itp data/test.ps
3. test not run, issues a prompt.

What is the expected output? What do you see instead?

Expected to run the data/test.ps program in the interpreter. Instead it issues 
a PS> prompt in the same way it does if no command-line arguments were given.

Please use labels and text to provide additional information.

What steps will reproduce the problem?
1. make
2. library created does not export full program functionality
3.

What is the expected output? What do you see instead?

It is expected to be able to link xpost - The Library - as a component
of a third-party program. It should accept configuration parameters to return 
output to the calling program and to execute specified postscript fragments 
either by filename or as a string buffer. 

Please use labels and text to provide additional information.

What steps will reproduce the problem?
1. make, make install
2. itp
3. no graphics window

What is the expected output? What do you see instead?

As a postscript interpreter, Xpost will be used to preview postscript graphics 
and documents. It should open a Window and display graphical output either 
after `showpage` or after all painting operators.

Please use labels and text to provide additional information.

What steps will reproduce the problem?
1. 1 dict dup readonly pop
2. /a 1 put
3. should trigger an /invalidaccess error

What is the expected output? What do you see instead?

Dictionaries (and files) have the same access in all shared copies 
of the object. So the access functions in xpost_object.c should store the 
access level in vm with the data so it is shared.

Please use labels and text to provide additional information.

What steps will reproduce the problem?
1. make
2.
3.

What is the expected output? What do you see instead?

`make` makes a program called 'itp'. The project is called "Xpost". ??!

The program should be called 'xpost'.

Please use labels and text to provide additional information.

What steps will reproduce the problem?
1. xpost_client
2. xpost_client_out.ppm contains incompletely filled circle

also exhibited by xpost_main with
3. 300 400 100 0 360 arc fill

What is the expected output? What do you see instead?

It should draw a big black circle. Instead there's a faint circular outline, 
and a chord from (0,+r) to (+r,0) is filled.

Please use labels and text to provide additional information.

Since the same problem is exhibited in 2 different devices, that traces it to 
the path operators. I now suspect it's the way arc creates its curves.

What steps will reproduce the problem?
1. runtest is running out of 'ent's.
2.
3.

What is the expected output? What do you see instead?

runtest executes the file testdraw.ps which performs some
relatively simple postscript drawing with pseudo-randomly 
generated points. It really ought to execute this program
without difficulty.


Please use labels and text to provide additional information.

What steps will reproduce the problem?
1. execution of operator objects
2.
3. algorithmic improvement -> possible order-of-magnitude speedup

What is the expected output? What do you see instead?

Operator objects are executed by a series of simple steps,

  * get pointer to OPTAB, the operator table
  * get struct oper object from optab
  * get signature block (a character string of type* ids)
  * iterate through signatures
    * check signature against stack
    * copy args from stack to holding-stack
    * call op-function associated with *this* matched signature
      accessing hold-stack contents via pointers

The "check signature against stack" is the problem here (and it was pieces of 
this "optimization" that led to the unnecessary UINT128 which isn't portable). 
*The type ids in the signature are extended with "pattern types": anytype which 
matches any object (count has already been checked previously), numbertype 
which matches either int or real, floattype which matches reals and promotes 
ints to reals, and proctype which is shorthand for executable array. Now the 
executable attribute is already in the tag field where the type is stored, but 
to pack these signature blocks tightly, these are stored as characters and 
masked to just the bits of the type sub-field, so the extended-type-id patterns 
do not clash with the flags which may use the higher bits. Hm... That detail is 
not particularly important here, but is for descriptive purposes. :)

The current implementation is what I usually call "the nasty loop". It's in 
xpost_operator.c:opexec()//

  * for each signature
    * if stack_count < sig.args
       - err = stackunderflow, next signature
    * for each type-pattern in sig
       * if anytype, 
           next type-pattern
       * if type-pattern matches the type of the stack object in that position,
           next type-pattern
       * if pattern is numbertype and corresponding stack object is int or float,
           next type-pattern
       * if pattern is floattype
           * if stack object is int
              promote to float
           * if stack object is real
              next type-pattern
       * if pattern is proctype
             and stack object is array
             and stack object is executable
              next type-pattern
       * else
           err = typecheck
           next signature

What I'd really like to do is match this type object as a large integer with 
bitwise logic. 8 bytes is 64bits, or UINT64 or unsigned long long. So the 
program logic could be simpler:

    * take "digest" of stack types
    * for each signature
        * compare type-pattern-block word-wise against digest
        * if good, 
           call op-function and return success
    * return error

The word-wise type comparison then becomes a nasty logic puzzle, but look how 
clean the code becomes!!! It's sooo pretty, it's *got* to be fast. Look at how 
many conditional branches are eliminated! That's got to zip through the 
pipeline faster, right? right? amiright??!

Please use labels and text to provide additional information.

What steps will reproduce the problem?
1. All graphics operations
2.
3.

What is the expected output? What do you see instead?

Graphics operations have to perform dictionary lookups with
name objects, but the creation of the name object from a string
is an additional layer of processing which could be removed
from the graphics operators and placed in the initialization.

Please use labels and text to provide additional information.

add a configuration module to store, save and load options and status

int xpost_file_read(char *buf, int size, int count, Xpost_File *fp)
{
    int i, j, k = 0;

    for (i = 0; i < count; ++i)
        for (j = 0; j < size; ++j)
            buf[k++] = xpost_file_getc(fp);

    return i;
}

{currentfile 10 string readstring pstack} exec
abc

{currentfile 10 string readstring exch print not {exit} if} loop
This is several lines
of text, these should be
printed exactly as they
appear in the input and
should end just after the
end of this sentence, with
any newlines that were in
the input.

What steps will reproduce the problem?
1. save (myfile)(w)file
2. restore
3. file should be closed now.

What is the expected output? What do you see instead?

The save/restore mechanism needs an extra record type and behavior to track 
file objects. File creation operators must register their objects with the save 
stack. Restore must close file objects if their Low-Level is above the new 
level.

Please use labels and text to provide additional information.

What steps will reproduce the problem?
1. There is a hard maximum of 65535 'ent's accessible through the PS object
2. This means that there may only be 65535 vm allocations, total, per memory 
file, including all strings, dicts, names, um, arrays. Each of these is an ent.
3. This imposes a constraint on program complexity lower than the PLRM 
describes.

This burden could be somewhat relieved by including the type of the object as 
an additional memory identifier.

I propose to add additional SPECIAL entities SPECIAL_ARRAY SPECIAL_DICT 
SPECIAL_STRING to each memory file's table-zero. These special ents would point 
to head's of additional memory-table-chains specifically for objects of that 
type. Names and strings would still share the same space.

This would permit these limits:
65535 global names or strings
65535 local names or strings
65535 global arrays
65535 local arrays
65535 global dicts
65535 local dicts

Oh, and SPECIAL_FILE, too.

This would have an impact on the garbage collector logic, but I expect it would 
facilitate improvements there, too.

What steps will reproduce the problem?
1. testfont
2.
3.

What is the expected output? What do you see instead?

Under mingw, I see the correct output. Under Cygwin, I see gibberish, but 
visible gibberish. Under Linux (Ubuntu), I get error 35, which according to 
/usr/include/freetype2/freetype/fterrdef.h means:

  FT_ERRORDEF_( Invalid_Face_Handle,                0x23, \
                "invalid face handle" )


Please use labels and text to provide additional information.

What steps will reproduce the problem?
1. The path structure is a large memory burden.
2.
3.

What is the expected output? What do you see instead?

The path data structure is referenced in most drawing operations
up to the final 'stroke' or 'fill' operations which execute a 
painting method in the device.

If implemented in C, it could use the Xpost_Stack for extensible
lists, even representing the path in normal postscript syntax:
10 10 moveto 20 20 lineto 30 30 40 40 50 50 60 60 curveto closepath

The path implementation would need to interact with the (currently)
postscript-level implementation of the graphics state. Probably in a
similar manner to the device implementations, by adding a /Private
member to the gstate dict.

There should be speed improvements from this as well, since many 
postscript actions would be replaced by a single postscript action.

Please use labels and text to provide additional information.

What steps will reproduce the problem?
1. mingw: testfont
2. Cygwin: 100 100 moveto /Times-Roman 40 selectfont (Hello World!) show
3.

What is the expected output? What do you see instead?

When using a .fon font in mingw or a .pcf.gz font in Cygwin, the
font is much smaller than the requested point size of 40.


Please use labels and text to provide additional information.

What steps will reproduce the problem?
1.
2.
3. all curve drawing

What is the expected output? What do you see instead?

Xpost currently converts curves into line segments using a recursive 
DeCasteljau subdivision. But there's an algorithm called "adaptive subdivision" 
which may be quite a bit faster (and with better quality) by reducing the 
number of line segments on the uninteresting spans of the curve.

Illustration:
http://codegolf.stackexchange.com/a/22155/2381

Article:
http://www.antigrain.com/research/adaptive_bezier/index.html#PAGE_ADAPTIVE_BEZIE
R

Please use labels and text to provide additional information.

[deleted issue]

What steps will reproduce the problem?
1. uncommenting the "orientation box fill" in testdraw.ps
2. Triggers an invalid object error 2 pages later in the fat curves.
3.

What is the expected output? What do you see instead?

It should execute all of this code with no difficulty. Mysterious bug. I 
strongly suspect the save/restore mechanism and/or garbage collection.


Please use labels and text to provide additional information.

What steps will reproduce the problem?
1. make, make install
2. itp -DDEVICE=pgm -o fern.pgm fern.ps
3. no file created

What is the expected output? What do you see instead?

Expected to create a pgm file (for example) containing a rendering of the image 
described by fern.ps.

Please use labels and text to provide additional information.

xpost_log_init() uses mkstemp() to create a unique file name, but the file is 
temporary. We should use another method to create a safe non temporary file

What steps will reproduce the problem?
1. (\0)cvn ()cvn eq
2.
3. ==> yields true,  should be: false

What is the expected output? What do you see instead?

Nametype objects should be able to contain nul (zero) characters
as part of the identifier. 

Please use labels and text to provide additional information.

This is the last holdover of using the "C" string convention
(nul designated the end of the string) in the interpreter.
Everywhere else, counted (+optional offset) strings are used.
And the actual char*s are handled very carefully since 
memory may move and invalidate the pointer after any new 
allocation.

Returning the string identifier is already content-transparent
as the associated strings for the name integer code is in a
stack of objects, which is already generic.

But the string->integer conversion is done with ternary search
tree which uses a test for nul as the recursion bound in tree
creation, and the success criterion in tree search.

So, the search tree itself needs to be redesigned to carry
an extra count variable in the creation calls, and to designate
an end-of-string property for a tree node.

add opengl support for faster rendering

currently, on Windows and unix, GDI and XCB are used. OpenGL and shaders can be 
used to improve rendering

What steps will reproduce the problem?
1. xpost -d pgm
2. runtest
3.

What is the expected output? What do you see instead?

There are some errors about bad memory access on one of the later pages, and 
then the fat curves page errors-out.

Please use labels and text to provide additional information.

What steps will reproduce the problem?
1. (... EOF
2.
3.

What is the expected output? What do you see instead?

An open paren that is not followed by a close paren before EOF
should result in a syntaxerror. Observed result is a valid string 
object and no error message.

Please use labels and text to provide additional information.

What steps will reproduce the problem?
1. {(})}
2.
3.

What is the expected output? What do you see instead?

It should construct a procedure containing a string containing
the single right-curly-brace character.

Instead, there is an /undefined error and an empty procedure
is left on the stack.

Please use labels and text to provide additional information.

What steps will reproduce the problem?
1. / = exec
2.
3.

What is the expected output? What do you see instead?

Should read as the empty literal name "/" and the executable name "=", which 
should print a newline to stdout.

Instead it triggers an /undefined error.

Please use labels and text to provide additional information.

What steps will reproduce the problem?
1. Running xpost in VirtualBox Ubuntu
2. 612x792 window doesn't fit in 800x600
3.

What is the expected output? What do you see instead?

If the screen doesn't support the requested dimensions, xpost should
create a smaller window of the correct proportions. We can use the
device's default matrix to compensate, so the ps program still sees
612x792.

May need to adjust fillpoly to ensure that narrow lines are still 
visible. 0-width will still bypass to a single-pixel line. But lines
of width 1 may disappear with the current polygon fill algo.

Please use labels and text to provide additional information.

        do
        {
            c[0] = xpost_file_getc(f);
            if (c[0] == EOF) ++eof;
        } while(!eof && strchr(hex, c[0]) != NULL);

        do
        {
            c[0] = xpost_file_getc(f);
        } while(strchr(hex, c[0]) != NULL);

    int eof = 0;
    …
    for (n = 0; !eof && n < S.comp_.sz; n++)
    {
        do  { … no gotos … } while(!eof && …);              [exit do-while loop if we get to EOF but stay in for]
        if (!eof)
            … not taken if we're now at EOF …
        else
        {
            c[1] = '0';
        }
        s[n] = ((strchr(hex, toupper(c[0])) - hex) << 4)    [c[0] is EOF so we calculate NULL - hex]
             | (strchr(hex, toupper(c[1])) - hex);
    }                                                       [and we'll execute the n++ in the for before exiting]
    S.comp_.sz = n;                                         [so, we'll set .sz to 1]

{currentfile 3 string readhexstring exch print not {exit} if} loop
54657374696e670a

What steps will reproduce the problem?
1. All computation
2. Is slower than it ought to
3. bbbbbb eeeeeee .......

Both the stacks and the memory tables are designed as a linear chain of 
segments. 

Adding a new element to the collection involves traversing the chain to find 
the top segment, and for the tables at least, the 'top' index of the top 
segment from which to calculate an absolute index. Performance would likely 
improve (subject to measure) by caching the address of this topmost table in 
the "head" segment. And also cache the top-segment's 'top' index and current 
number of segments to quickly calculate indices.

If the stack is indexed from the bottom, the (necessary?) linear search from 
below going straight to the element. But indexing from above must first search 
the entire stack to produce a count in order to perform the bottom-up search. 
The count property of the stack, could be made much cheaper by caching the 
value in the "head" segment.

Indexing from the top might also make use of the top-segment address and top 
index to avoid linear searching on the top elements (up to a segment size). For 
more consistent application of this shortcut (at least 1 segment size, up to 2 
segment sizes), we could also cache the 2nd-topmost segment address. 

What steps will reproduce the problem?
1. buffer is implemented as ps arrays
2. array contents are subject to save/restore
3. thus, buffer contents are modified by save/restore

What is the expected output? What do you see instead?

save/restore resets the contents of all arrays and dictionaries. The raster 
output of the device should be immune to these effects.

Therefore the buffers should be implemented as strings. Best as 1 single string 
accessed by an array of substrings. Thus the "array contents" do not "change" 
and restore won't affect anything, and the string contents are immune to 
save/restore naturally.

This change will affect data/pgmimage.ps data/ppmimage.ps and 
src/lib/xpost_dev_bgr.c 

Please use labels and text to provide additional information.

What steps will reproduce the problem?
1.
2.
3. http://www.tinaja.com/glib/ps8dprp1.pdf

What is the expected output? What do you see instead?

Document describes a technique for getting 8 decimal digits
out of a 32-bit IEEE 754 float in a postscript environment.

Xpost uses a custom C procedure to implement number-to-string
conversions, and could adopt these techniques internally.

Please use labels and text to provide additional information.