[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Can DPSshow be implemented by _showString:xCharAdj:yCharAdj:char:adj
From: |
Fred Kiefer |
Subject: |
Re: Can DPSshow be implemented by _showString:xCharAdj:yCharAdj:char:adjArray:arrType:isRelative: ? |
Date: |
Sun, 08 Aug 2010 16:52:33 +0200 |
User-agent: |
Mozilla/5.0 (X11; U; Linux x86_64; de; rv:1.9.1.11) Gecko/20100714 SUSE/3.0.6 Thunderbird/3.0.6 |
Am 06.08.2010 03:31, schrieb Derek Fawcus:
> I see that most of the other DPS text output routines are implemented in
> terms of the
> above helper routine. Maybe I'm missing something, but is there any reason
> why
> DPSshow cannot also be implemented by it? Maybe something like:
>
> - (void) DPSshow: (const char*)s
> {
> float arr[2];
>
> arr[0] = 0; arr[1] = 0;
> [self _showString: s
> xCharAdj: 0 yCharAdj: 0 char: 0 adjArray: arr arrType: show_delta
> isRelative: YES];
> }
>
> added to Source/gsc/GSGState.m ?
>
> Which would then allow all of the backends (barring
> Source/xdps/NSDPSContextOps.m) to be simplified?
Sounds like an excellent idea to me. This will bring us down to just one
real string drawing implementation per backend. When implementing a new
backend I always wonder which of the different methods actually require
an implementation.
Perhaps we could even move all that code over to gui, but as far as I
remember from moving this up from the art backend this wasn't possible
at that time.
This implementation should be a lot slower then the old DPSshow in the
specific backends, but we could add a bit of optimisation in _showString
and then this code path isn't used anywhere in gui, so the slow down
would only affect old OpenStep applications still using the PS drawing
functions.