TODO list

[luserdroog]

The detailed list of operators implemented and otherwise is now in the source COMPLIANCE file. This list will now be more conceptual (and chatty).

 

The broad strokes:

 

  Level 1 operators

  Level 2 operators

  Display Postscript

  NeWS

  Typical output devices

 

Optimizing.

 

The dictionary module needs to be outfitted with statistics machinery in order to tune the hashing function. Right now it works just because it's logically correct. And may be faster or slower or anywhere in between. The performance characteristics are completely unknowable without better tools integrated into the source. And this is beyond my current knowledge.

 

As detailed in the memory thread, there are other planned algorithmic optimizations that are delaying until the program achieves better coverage and correctness.

 

Coverage and Correctness.

 

Most of level 1 is there. Some missing pieces are: even-odd stuff, complex interconnecting paths (Weiler-Atherton? Vatti? Weiler-Atherton? Vatti? Is there anything else? I bought a CG book by Max Agoston, but I got the math one by mistake. I've got a pdf of his write-up of Vatti, but his book looks like the major source for more like it. I've got the right one on-order now.)

 

I should add more tests to test.ps so it fails on any missing level 1 operators. That one started with just the examples from the manual, where the exact output is described. But there's no reason to restrict the testing to those published examples.

 

Some of level 2 is there: growing dicts, growing stacks, global/local memory. whew, that really was a lot to get working, I feel. :)  But we take a quick nap, and press-on!

 

Some other missing bits: Ascii85 syntax in the scanner.

 

For Display Postscript it needs multiple executing processes. And binary syntax in the scanner. Update: multiple contexts is implemented, following the Display Postscript syntax (it appears easier to implement the NeWS version on top of DPS rather than the other way around).

 

At some level in here, it will run as a "server" and create new internal processes as connections are made to its listening processes.

 

For NeWS, it will actually have a new design for the command-line part, connecting to the "server" from basically a telnet clone.

 

A few little tweaks I've noticed: There are 3 object flags that can be combined into 1, gaining 2 more extra bits to extend the ent field in a composite object. This gives 21 bits for the table index, over 2 million addressable allocations. That should put that issue to bed for good while.

 

Also the graphics base classes erroneously use arrays of integers to hold the raster buffer. This means the buffer contents are subject to save/restore, which does not conform to the standard. So the pgmimage and ppmimage implementations need to be rewritten using strings for the raster data.

 

[luserdroog]

A list of specific tasks that appear possible and desirable. Some of these are also issues. Some have been noticed before (upthread). But this is what I've currently got "on the table" so to speak.

 

 

## short term

 

implement size parameters to xpost_create().

 

implement auto-kerning control parameter.
(in each font? implement level2 user-params?)

 

collapse object flags: extended_int extended_real and opargsinhold.

implement gc controls in xpost_op_param.c:vmreclaim().

 

## longer term

 

 * unit testing

 * coverage report with gcov / lcov, or with coverall, see
https://coveralls.io/ (for coverage with unit tests)

  * automatic compilation and report with drone.io, see
https://drone.io/ (when changes are pushed, so we now if we have
pushed something wrong)

profile with callgrind.  profile postscript code with 

% Postscript Profiler from the Acumen Journal May 2003
% http://acumentraining.com/acumenjournal.html
 

remove optab from vm, thus removing all pointers.
- remove xpost_free_realloc();

 

extensible ps-init-files search ability.
or resource-compile the files into the executable.

 

anti-aliasing. Porter/Duff compositing? include alpha-channel?
can we specify rgba in ps with /DeviceN colorspace?
implement /DeviceN colorspace.

 

expose Type 1 font data to ps (export in dict).
accept modified Type 1 font dict in `definefont`.

 

Implement Vatti or Weiler/Atherton clipping for eoclip and clip.
Thus also implementing eofill and fill.

 

 

 

These last three items are "big" in the sense that I need to do

more research in order to do them. Other "big" items include

finally figuring out how to do a non-blocking read on a windows

console<-- this should greatly improve the "window" behavior

wrt redrawing.

 

[vincent.torri]

Le lundi 18 mai 2015 07:46:39 UTC+2, luserdroog a écrit :

A list of specific tasks that appear possible and desirable. Some of these are also issues. Some have been noticed before (upthread). But this is what I've currently got "on the table" so to speak.

 

 

## short term

 

implement size parameters to xpost_create().

 

implement auto-kerning control parameter.
(in each font? implement level2 user-params?)

 

collapse object flags: extended_int extended_real and opargsinhold.

implement gc controls in xpost_op_param.c:vmreclaim().

 

## longer term

 

 * unit testing

Unit testing framework is here, there are some unit tests, but more must be added
 

 * coverage report with gcov / lcov, or with coverall, see
https://coveralls.io/ (for coverage with unit tests)

coverage report with gcov/lcov is done. Not sure that coveralls.io is necessary
 

  * automatic compilation and report with drone.io, see
https://drone.io/ (when changes are pushed, so we now if we have
pushed something wrong)

drone.io integration is done
 

[luserdroog]

Priorities have drifted somewhat over time, but a new list of TODOs has emerged.

  * fix all compiler warnings. compile with -std=c99 and -pedantic-errors

  * charpath operator

     for Type 1 fonts this means lots of fiddly interfacing with FreeType to dissect its path structures.

     for Type 3 fonts this means some fiddly code at the postscript level. And i'll need a type 3 vector font to test it with. All the Type 3 handling has so far been tested only with my bitmap font.

  * The Pattern Colorspace.

     due to the nature of the graphics pipeline, only fills need to do this. It involves a sort of recursive use of the graphics system. Or a pattern-caching system.

  * Output to PDF.

     for simplicity, I plan to target the PDF 1.3 standard from 2001. not too old (it misses the bookmarks feature which was added in 1.4 with the tagging ability), but not too new that the spec has tons of extra detail and bells and whistles.

These are the parts where my attention will be focused for the time being.  

- Josh (luser droog)

[Ross Presser]

It seems to have been nearly a year since this post, and nearly a year since your last commit on GitHub ... is the project pining for the fjords? 

[luserdroog]

I'm kind of at a crossroads with the project. I think what needs to

happen is a top-down redesign and recoding. Designing from API -in and from the graphics device -in. I want the example client to illustrate making a custom device to capture events.

But it all seems like a ton of work and I just never find myself 

wanting to get started on it. 

I've had a bunch of gigs playing bass in local musicals and that 

has eaten up a lot of my programming time. As a side-effect,

I'm now hooked on watching youtube videos demonstrating

guitar effects pedals.

So, that's the status. Awaiting some influx of energy or time or

something.