Re: Interesting Bug with LuaTex, \setfontfeature{oldstyle}, colors and tikz

Hi!

seems like someone changed the color handling internals in ConTeXt.  
Hmm... Right now, pgf hacks into ConTeXt color internals, "hoping"  
that this will work. Obviously, it no longer does. Sigh.

As an ultra-quick-fix, try

\let\definecolor=\pgfutil <at> definecolor
\definecolor{zeug}{rgb}{1,0,0}

This is not a solution, but may help a bit...

Sorry about this,
Till

Am 30.09.2008 um 14:30 schrieb Holzminister:

> Hi!
>
> Please help, without colors I'm stuck. :)
>
> Best regards,
> Eyke
>
> Am Thu, 18 Sep 2008 09:38:25 +0200
> schrieb holzminister <holzminister <at> googlemail.com>:
>
>> Hi!
>>

foreach loops and counter arithmetic.

I am curious about the best or idiomatic way to do simple arithmetic  
on the counter variable in a \foreach loop?  What I have been doing is  
defining a separate counter outside of the loop, and using the calc  
package to update that counter during each loop iteration.  But then I  
must convert the counter back to a string for use in tikz node names.

Is this a reasonable way of approaching the situation?  Could I do  
better?

Alex Ross
http://cs.pdx.edu/~ajross

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

_______________________________________________
pgf-users mailing list
pgf-users <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pgf-users

Scaling of plot data

Hi,

is it possible to scale plot data before it is used?

I would like to use the original data as my input but when I scale it with:

\draw[xscale=5] plot[only marks,mark=x] file {plot.slack.table};

The marks are also scaled. Is there a way to get the result without scaled 
marks?

Chrsitoph

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: foreach loops and counter arithmetic.

Le 1 oct. 08 à 14:56, Alex Ross a écrit :

> I am curious about the best or idiomatic way to do simple arithmetic  
> on the counter variable in a \foreach loop?  What I have been doing  
> is defining a separate counter outside of the loop, and using the  
> calc package to update that counter during each loop iteration.  But  
> then I must convert the counter back to a string for use in tikz  
> node names.
>
> Is this a reasonable way of approaching the situation?  Could I do  
> better?
>
> Alex Ross
> http://cs.pdx.edu/~ajross

hello Alex,

First thanks for your works on Textmate !

now for your question

  with pgf 2.00 ( not the cvs version) it's possible to work without  
calc.sty and the module calc

\documentclass{article}

\usepackage{tikz,xifthen}

\begin{document}

Vector addition

Hello,

The following seems to work:

\path (90-1*360/14:3.5)+(0:2.5) node (east-eu-backbone) {east european};

but

\path (90-1*360/14:3.5)+(0:2.5)+(30:4) node (east-eu-backbone)
{east_european};

More general, it seems like the math feature of PGF/TikZ doesn't allow
multiple (more than two) terms. Is that the case, or am I missing
something?

I've also attempted

\path ((90-1*360/14:3.5)+(0:2.5))+(30:4) node (east-eu-backbone)
{east_european}; without success...

Cheers,

mh

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: Vector addition

Le mercredi 01 octobre 2008 à 17:39 +0200, Michael Hallgren a écrit :
> Hello,
> 
> The following seems to work:
> 
> \path (90-1*360/14:3.5)+(0:2.5) node (east-eu-backbone) {east european};
> 
> but
> 
> \path (90-1*360/14:3.5)+(0:2.5)+(30:4) node (east-eu-backbone)
> {east_european};
> 
> More general, it seems like the math feature of PGF/TikZ doesn't allow
> multiple (more than two) terms. Is that the case, or am I missing
> something?
> 
> I've also attempted
> 
> \path ((90-1*360/14:3.5)+(0:2.5))+(30:4) node (east-eu-backbone)
> {east_european}; without success...

Maybe I should add that what I'm attempting to do is to place circles,
generated by ests of nodes on the perimeter, relatively (and sometimes
slightly overlapping).

Is there a better way to achieve this, than using vector addition to 
translate the circles (circle origins) into position?

Thanks,

3D-ready ellipses with TikZ

Hi,

today I found out about the xyz coordinate system in TikZ. So I played
around a bit, but I miss an important feature: drawing ellipses (and
eventually arcs) in 3d. In order to do this it should be possible to
specifiy the semiminor and semimajor axis as a vector instead of just
two scalar "radii" as in the current TikZ implementation.

After some tries to manually create an ellipse with the bezier curves I
found out that the PGF command \pgfpathellipse uses such kind of arguments.

Though looking into tikz.code.tex didn't really help my on how to
implement this thing on my on - I think I've just to little experience
with tikz. Hopefully this problem just takes 2 minutes for someone more
familiar with the tikz internals. Actually I understand how
\tikz@@ellipseB works but I have no idea how this is called when
something like "\draw ellipse(...)" is parsed.

Here's my (not-so-minimal) example:
Important lines between the *****

% ---- SNIP ----
\tikzstyle{perspective dimetric}=[%
x={(0.9428,-0.1179)},%
y={(0.0,0.9354)},%
z={(-0.3333,-0.3333)}]

\begin{tikzpicture}[perspective dimetric]

% Draw cross

Re: Vector addition

Le mercredi 01 octobre 2008 à 20:09 +0200, Kjell Magne Fauske a écrit :
> On Wed, Oct 1, 2008 at 5:39 PM, Michael Hallgren <m.hallgren <at> free.fr> wrote:
> > Hello,
> >
> > The following seems to work:
> >
> > \path (90-1*360/14:3.5)+(0:2.5) node (east-eu-backbone) {east european};
> >
> > but
> >
> > \path (90-1*360/14:3.5)+(0:2.5)+(30:4) node (east-eu-backbone)
> > {east_european};
> >
> > More general, it seems like the math feature of PGF/TikZ doesn't allow
> > multiple (more than two) terms. Is that the case, or am I missing
> > something?
> >
> > I've also attempted
> >
> > \path ((90-1*360/14:3.5)+(0:2.5))+(30:4) node (east-eu-backbone)
> > {east_european}; without success...
> >
> > Cheers,
> >
> > mh
> >
> > -------------------------------------------------------------------------
> > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> > Build the coolest Linux based applications with Moblin SDK & win great prizes
> > Grand prize is a trip for two to an Open Source event anywhere in the world

Re: Vector addition

On Wed, Oct 1, 2008 at 10:49 PM, Michael Hallgren <m.hallgren <at> free.fr> wrote:

> With more detail. The problem is showing up in the placement of the
> ``w1t'' and ``wzn'' nodes...
>
<snip>
> %% east_eu_backbone
> \path (90-13*360/14:2cm)+(90-1*360/14:3.5)+(45:0.75) node (w1t) {w1t};
> \path (90-13*360/14:2cm)+(90-1*360/14:3.5)+(-45:0.75) node (wzn) {wzn};
>
>
> \path (90-13*360/14:2cm)+(90-1*360/14:3.5)+(-45:0.75) node (wzn) {wzn};
>
>
> Missing something obvious?
>

Sorry, I misunderstood your problem. You probably want to use ++
instead of +. The + operator does not update the current coordinates.
The ++ operator does that. See chapter 12.4.1 Specifying Relative
Coordinates for details. The + or ++ is not a vector addition. It
tells TikZ to place the coordinate relatively to the previous one.

Tip. For placing the nodes you can use the 'chains' library. Here is a
simple example:

%%%
\documentclass{article}
\usepackage{tikz}
\usetikzlibrary{chains}

Re: Vector addition

Le jeudi 02 octobre 2008 à 10:01 +0200, Kjell Magne Fauske a écrit :
> On Wed, Oct 1, 2008 at 10:49 PM, Michael Hallgren <m.hallgren <at> free.fr> wrote:
> 
> > With more detail. The problem is showing up in the placement of the
> > ``w1t'' and ``wzn'' nodes...
> >
> <snip>
> > %% east_eu_backbone
> > \path (90-13*360/14:2cm)+(90-1*360/14:3.5)+(45:0.75) node (w1t) {w1t};
> > \path (90-13*360/14:2cm)+(90-1*360/14:3.5)+(-45:0.75) node (wzn) {wzn};
> >
> >
> > \path (90-13*360/14:2cm)+(90-1*360/14:3.5)+(-45:0.75) node (wzn) {wzn};
> >
> >
> > Missing something obvious?
> >
> 
> Sorry, I misunderstood your problem. You probably want to use ++
> instead of +. The + operator does not update the current coordinates.
> The ++ operator does that. See chapter 12.4.1 Specifying Relative
> Coordinates for details. The + or ++ is not a vector addition. It
> tells TikZ to place the coordinate relatively to the previous one.

Thanks to your kind reply and rtfm, I now understand the mechanism.

> 
> Tip. For placing the nodes you can use the 'chains' library. Here is a
> simple example:
>