 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 19 Nov 2009 13:36:13 +0100, Invisible <voi### [at] dev null> wrote:
>
> However, for both PostScript and PDF [the formats I'm actually
> interested in], the default origin point is actually the bottom-left
> corner, not the top-left.
>
> In addition to this, both of these formats allow the coordinate space to
> be arbitrarily transformed. (Cairo provides the same functionallity
> itself as well, but PS and PDF have it natively.) So I'm not sure if
> Cairo is using the native defaults, or transforming them to match the
> other backends, or...?
Then how about you just try it, and find out?
--
FE
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible schrieb:
> Now, can *anybody* figure out what the default coordinate space is?!
>
> Seriously, I can't find this information anywhere in the documentation.
> Is (0,0) at the bottom-left corner? The top-left corner? Somewhere else?
> What??
>
> It seems this is so trivial they forgot to actually write it down. >_<
Experience indicates that everything that virtually all graphics output
frameworks have (0,0) at the top-left corner - and the samples confirm
that it is the case here as well.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible schrieb:
> In addition to this, both of these formats allow the coordinate space to
> be arbitrarily transformed. (Cairo provides the same functionallity
> itself as well, but PS and PDF have it natively.) So I'm not sure if
> Cairo is using the native defaults, or transforming them to match the
> other backends, or...?
Why not just... try it out?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> It seems this is so trivial they forgot to actually write it down. >_<
That's OK. The graphics lib I'm workign with takes R, G, B, and A. And
sometimes A=0xFF means opaque and sometimes it means transparent. And you
get to guess for any given function whether A comes first in the list or last.
--
Darren New, San Diego CA, USA (PST)
Is God willing to prevent naglams, but unable?
Then he is not omnipotent.
Is he able, but not willing, to prevent naglams?
Then he is malevolent.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> That's OK. The graphics lib I'm workign with takes R, G, B, and A. And
> sometimes A=0xFF means opaque and sometimes it means transparent. And
> you get to guess for any given function whether A comes first in the
> list or last.
Wow, that's pretty sweet, man.
That's almost as good as the threadDelay function, that doesn't tell you
whether the argument is seconds or miliseconds or picoseconds or...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> That's almost as good as the threadDelay function, that doesn't tell you
> whether the argument is seconds or miliseconds or picoseconds or...
Probably biliseconds.
--
Darren New, San Diego CA, USA (PST)
Is God willing to prevent naglams, but unable?
Then he is not omnipotent.
Is he able, but not willing, to prevent naglams?
Then he is malevolent.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> In addition to this, both of these formats allow the coordinate space
>> to be arbitrarily transformed. (Cairo provides the same functionallity
>> itself as well, but PS and PDF have it natively.) So I'm not sure if
>> Cairo is using the native defaults, or transforming them to match the
>> other backends, or...?
>
> Why not just... try it out?
In the PostScript case, since Ghostscript insists on displaying every PS
file under the assumption of A4 paper, it's hard to decide where Cairo
thinks the edge of the paper is. PDF works correctly, however, and this
indicates that Cairo is indeed translating and reflecting the coordinate
system such that the origin is the top-left corner.
They could have saved me a whole heap of trouble if this were written
down somewhere. (Note that it doesn't even say what the coordinate
system is for image surfaces either...)
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 wrote:
> They could have saved me a whole heap of trouble if this were written
> down somewhere.
Report it, then. Or even send them a patch, if the documentation source
files are available.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New schrieb:
> Invisible wrote:
>> That's almost as good as the threadDelay function, that doesn't tell
>> you whether the argument is seconds or miliseconds or picoseconds or...
>
> Probably biliseconds.
Billyseconds?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka a écrit :
> Darren New schrieb:
>> Invisible wrote:
>>> That's almost as good as the threadDelay function, that doesn't tell
>>> you whether the argument is seconds or miliseconds or picoseconds or...
>>
>> Probably biliseconds.
>
> Billyseconds?
no, bilisecond, from the USA/MS nomenclature :
bil : 1000 mil (million, billion...)
and the isecond unit (inverted second)
milisecond is 1/1000 second,
so bilisecond is 1000 times that, 1/1000000 s.
(From the thread about MS api)
I now expect a precision of femtosecond in timestamps...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
