Click for: WEBPAGE INDEX
web page last updated Sunday 27th April 2003 930pm
======= SUMMARY of developments ==========
This SUMMARY will be continuously updated.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%
LATEST HEADLINE:
Sun 27th April 2003 930pm:
View for yourself tiny fonts
done with the new gs8 24 bit rgb turboprint subdevice. This is a
jpeg of a closeup of a scan of a printout via a
Canon_S820 printer by tester DarkAngel@blackbunker.de
In the top line the "A" is 2mm high and in the lowest
line it is 0.5mm high. Have a look at the "%"'s and
see that the circles are perfectly formed.
The 3 flagship turboprint devices: 24 bit rgb tp24,
8 bit 256 shades of gray tp8g, and
the fast 1 bit b/w tp1 are now all functioning
correctly without any known problems. Currently we are doing
quality control tests on these 3 devices. The above
closeup is an example of such a quality control test.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Sun.20.apr.2003.130am:
PROOF: view for yourself a closeup scan of a succesful GS8 24bit
turboprint printout of GS8:examples/tiger.eps
done by turboprint tester DarkAngel using a Canon_S820 printer:
tiger_closeup.jpg
You can view it with whooshjpeg.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Turboprint 24 bit rgb and 1 bit b/w are now fully functioning.
8 bit gray prints but has problems on exit, these are being looked into.
Also being worked on is clean exit on control-c for turboprint devices.
:currently it can lead to a crash. But I think I have a correct
initial mechanism in place.
Fri.18.apr.2003.130am: VICTORY!!!
A very energetic turboprint tester emailed me today to say
that 24 bit turboprint is now fully functioning with no colour
inversion or reversion problems. So the new GS8 can now print through
Turboprint in 24 bit colour by -sDEVICE=tp24.
And it appears that we also have GS8 printing correctly via Turboprint in
1 bit colour: -sDEVICE=tp1
The amount of energy needed to achieve this defies description.
I am feeling completely exhausted by the whole procedure.
Next on our list is 256 shades of gray printing.
Beyond that lies 16 bit and 256 colour printing. :I'm not sure there's
much point in these 2 methods. 16 bit uses 5 + 6 + 5 bits and
256 colour uses 3 + 3 + 2 bits (in some order).
These irregular bit formats dont appeal to me. You shouldnt sacrifice
regularity just for 1 bit. 15 bits would be more sensible than 16,
the problem is trying to communicate this to GS8.
GS8 is geared around things like 24 bit rgb, 256 shades of gray and
1 bit. If you use these you get built in + thought through + correct
colour conversion etc. Once you go beyond these 3 its a lot of effort
and more trouble than its worth IMO.
I bet nobody out there uses these 16bit and 256colour methods.
If you can print your image in 16 bit then you should be able
to print it in 24 bit. Really I believe that people who have bought
a modern colour printer will want 24 bit.
However if 16 bit and 256 colour function as-is then I'll include
them.
You may wonder what the point of 1 bit printing is when you have
24 bit:
:Answer: 1 bit printing is very fast and has very low memory overhead.
So if you want to print a 100 page text only manual in pdf it will
happen a lot faster with 1 bit than 24 bit. But OTOH if you want to
print a colourful photo of some festivity use 24 bit.
Use the right tool for the job. Think about it this way, with 1 bit,
8 pixels get printed for
every byte, whereas for 24 bit 3 bytes are needed for every pixel.
8bit gray is interesting because it gives you photorealism
for a small number of bits, not as clever as HAM8 though which
originates from NASA transmitting colour photos through outer space
(I think)!
Thur.17.apr.2003.130am: 2 new TURBOPRINT BREAKTHROUGHS!:
BREAKTHROUGH 1. One of my testers sent me a scanned image of a succesful printout
of the tiger, done in low res (72 or 85 dpi) in full colour
via -sDEVICE=whoosh communicating to Turboprint.
BREAKTHROUGH 2. The same turboprint tester sent me a scanned printout
jpeg via -sDEVICE=tp24 which is the new 24 bit turboprint device.
He also sent me a jpeg of the actual doc,
The printout was very impressive but red and blue appeared
to have been exchanged. Eg a red cable in the one image was blue in the other.
After scrutinizing the source code I found out why:
the source code uses "CMY - direkt". This explains those colour inversion
problems. Anyway I have reverted the code to rgb24 and not cmyk. See the
update for Thur 12 Apr why I regard rgb as a better approach than cmyk.
Another TURBOPRINT BREAKTHROUGH!!
Successful 24 bit rgb prints have been achieved via GS8's
turboprint devices. Still some problems with inverse-colour
printouts: some printouts are coming out alright via GS8 but
in inverse colour via Apdf and vice versa also! Not clear
where the problems lie but it should be fixable.
The GS8-turboprint printing seems to be faster than via
GS510-turboprint: this is probably because AFPL GS have done a lot of
work speeding up the internal GS8 rendering routines.
ie the speedups are GS8 speed ups rather than
-sDEVICE=turboprint
speedups. This is one of the merits of modular design: replace
one module and the whole system can receive a big boost.
And these speed ups are on an unoptimized no FPU 68020 recompile. So you can
imagine the speed ups that will come with an optimized
68060 version. Note that it is possible that a no FPU
version might be faster than an FPU version due to clever
integer maths.
%%%%%%% previous update:
BIG BREAKTHROUGH!!!
At 3:30pm I received an email from one of the
turboprint testers that
-sDEVICE=turboprint with 2 colour b/w monochrome
is printing correctly at last!!!
He says that 8 bit gray and 8 bit colour also print but with lurid colours,
24 bit rgb and 16 bit rgb crash with the Guru giving Number 80000005
to meditate on. This we do and it is revealed to us by a higher source
(exec/alerts.h) that the CPU has divided by zero. :This seems to be a
favourite printer.device error.
Anyway some interesting new tests are being prepared.
%%%%%%%%%%%%%%%%%%%% PREVIOUS UPDATE on turboprint:
Major progress:
With the new parameters, -sDEVICE=turboprintis almost printing now.
I have figured out a brute force trick to obtain the full +
correct parameter list, maybe then -sDEVICE=turboprint will
finally begin to print. GS8 will not give up its parameters
without a fight! Realistically It will take some hours to go through the
full parameter extraction procedure.
Who knows, with the fully correct parameters
it may even outperform the official GS510!
That would be some achievement!!
One of my testers obtains very healthy debug output
finally terminating in a divide by zero
crash from Turboprint, the other tester gets the full
printout procedure even reaches the GS> prompt but
no print. The difference in GS8 behaviour is because they
are using different output formats one is using 24bit rgb
the other tester is using a b/w or gray format
ie different parameter errors causing different failures.
This suggests that the parameters are all important.
Earlier update (1am):
Progress finally with turboprint, have found some 20 wrong
parameters. These lead to internal "rangecheck" errors.
Evidently these errors didnt matter on GS510, but they do
with GS8 due to tighter consistency checks.
