pyx-devel — PyX development

Re: [PyX-devel] compatibility with apache license?

[Joerg L. <jo...@us...>]

Hi John,

On 12.06.06, John Owens wrote:
> Over in pyx-user we've been discussing adding "ColorBrewer" color
> schemes (www.colorbrewer.org). Here's the license (below). It's
> "Apache-like". If we were to use them, it's clearly "source form"
> redistribution. I don't think adding the
> copyright/conditions/disclaimer is a problem, or the acknowledgement,
> or putting the appropriate text in the manual. The only thing I don't
> know about is the compatibility of this license with the GPL.

I fear that at the moment all Apache-like licenses are GPL incompatible,
at least according to the interpretation of the FSF:

        http://www.fsf.org/licensing/licenses/index_html

AFAIR, the GPL3 license should solve this problem, although this 
is not yet clear - the license not even existing in its final form.

        Jörg

[PyX-devel] compatibility with apache license?

[John O. <joh...@ya...>]

Over in pyx-user we've been discussing adding "ColorBrewer" color
schemes (www.colorbrewer.org). Here's the license (below). It's
"Apache-like". If we were to use them, it's clearly "source form"
redistribution. I don't think adding the
copyright/conditions/disclaimer is a problem, or the acknowledgement,
or putting the appropriate text in the manual. The only thing I don't
know about is the compatibility of this license with the GPL.
Thoughts?

JDO

# Copyright (c) 2002 Cynthia Brewer, Mark Harrower, and The
# Pennsylvania State University. All rights reserved. Redistribution
# and use in source and binary forms, with or without modification,
# are permitted provided that the following conditions are met:
# 
# -  Redistributions as source code must retain the above copyright
#    notice, this list of conditions and the following disclaimer.
# -  The end-user documentation included with the redistribution, if
#    any, must include the following acknowledgment:
#      This product includes color specifications and designs
#      developed by Cynthia Brewer (http://colorbrewer.org/).
#    Alternately, this acknowledgment may appear in the software
#    itself, if and wherever such third-party acknowledgments normally
#    appear.
# -  The name "ColorBrewer" must not be used to endorse or promote
#    products derived from this software without prior written
#    permission. For written permission, please
#    contact Cynthia Brewer at cb...@ps....
# -  Products derived from this software may not be called
#    "ColorBrewer", nor may "ColorBrewer" appear in their name, without
#    prior written permission of Cynthia Brewer.
# 
# THIS SOFTWARE IS PROVIDED "AS IS" AND ANY EXPRESSED OR IMPLIED
# WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
# MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
# IN NO EVENT SHALL CYNTHIA BREWER, MARK HARROWER, OR THE PENNSYLVANIA
# STATE UNIVERSITY BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
# SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
# LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
# USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
# ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
# OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
# OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
# SUCH DAMAGE.

[PyX-devel] ANN: PyX 0.9 released

[Andre W. <wo...@us...>]

Hi!

We're proud to announce the release of PyX 0.9! After quite some time
we finally managed to prepare a new major release. Many improvements
and fixes are included (see the attached list of changes), but there
are a couple of highlights which should be mentioned separately: This
release adds a set of deformers to PyX for path manipulations like
smoothing, shifting, etc. A new set of extensively documented examples
describing various aspects of PyX in a cookbook-like fashion have been
written. Type 1 font-stripping is now handled by a newly written
Python module. The evaluation of functions for graph plotting is now
left to Python. Thereby some obscure data manipulation could be
removed from the bar style for handling of nested bar graphs.
Transparency is now supported for PDF output.

Let me try to summarize some of the *visible* changes (to existing
code out there) we needed to apply to facilitate some of the major
goals of this release:

  - The path system has passed another restructuring phase. The
    normpath, which allows for all the advanced path features of PyX,
    have been moved into a separate module normpath. The
    parametrization of the paths (i.e. of the normpaths) is now
    handled by normpathparam instances allowing for mixing arc lengths
    and normpathparam instances in any order in many path functions
    like split etc. The normpathparam instances allow the addition of
    arc lengths to walk along a path, for example starting at the end
    of a path or at an intersection point.

  - The evaluation of mathematical expressions in the classes from the
    graph.data module is now left to Python. While this leads to a
    huge set of other improvements (like being not restricted to the
    floats datatype anymore), there are no differences between the
    evaluation of the expression compared to Python anymore. As Python
    by default still uses integer division for integer arguments, the
    meaning of a function expression like "1/2" has changed
    dramatically. In earlier versions of PyX for this example the
    value 0.5 was calculated, now it becomes 0. (I'm looking forward
    to Python 3000 to get rid of this situation once and for all! :-))

  - Bars graphs on a list of data sets, which in earlier versions have
    been automatically converted to use a nested bar axis, don't do
    that automatic conversion anymore. You may want to look at the
    example http://pyx.sourceforge.net/examples/bargraphs/compare.html
    to learn more about the new and more flexible solution.

  - The stroke styles linestyle and dash now use the rellength feature
    by default. Furthermore the rellength feature was adjusted to not
    modify the dash lengths for the default linewidth. Hence you're
    affected by this change when you have used the rellength feature
    before or you used linestyles on linewidths different from the
    default.

  - The bbox calcuation was modified in two respects: First it now
    properly takes into account the shape of bezier boxes (so the real
    bounding box is now used instead of the control box). Secondly PyX
    now takes into account the linewidths when stroking a path and
    adds it to the bounding box.


Happy PyXing ...

Jörg, Michael, and André


------------------

0.9 (2006/05/24):
  - most important changes (to be included in the release notes):
    - mathtree removal (warning about integer division)
    - barpos style does not build tuples for nestedbar axes automatically
    - new deformers for path manipulation (for smoothing, shifting, ... paths)
  - font modules:
    - new framework for font handling
    - own implementation of type1 font stripping (old pdftex code fragments removed)
    - complete type1 font command representation and glyph path extraction from font programs
    - t1code extension module (C version of de-/encoding routines used in Type 1 font files)
    - AFM file parser
  - graph modules:
    - data module:
      - mathtree removal: more flexibility due to true python expressions
      - default style instantiation bug (reported by Gregory Novak)
    - style module:
      - automatic subaxis tuple creation removed in barpos (create tuples
        in expressions now; subnames argument removed since it became pointless;
        adujstaxis became independend from selectstyle for all styles now)
      - remove multiple painting of frompath in histogram and barpos styles
      - fix missing attribute select when using a bar style once only (reported by Alan Isaac)
      - fix histograms for negative y-coordinates (reported by Dominic Ford, bug #1492548)
      - fix histogram to stroke lines to the baseline for steps=0 when two subsequent values are equal
      - add key method for histogram style (reported by Hagemann, bug #1371554)
      - implement a changebar style
    - graph, axis and style module:
      - support for mutual linking of axes between graphs
      - new domethods dependency handling
      - separate axis range calculation from dolayout
    - axis.parter module:
      - linear and logarthmic partitioners always need lists now
        (as it was documented all the time; renamed tickdist/labeldist
        to tickdists/labeldists; renamed tickpos/labelpos to
        tickpreexps/labelpreexps)
    - axis module:
      - patch to tickpos and vtickpos (reported by Wojciech Smigaj, cf. patch #1286112)
      - anchoredpathaxis added (suggested by Wojciech Smigaj)
      - properly handle range rating on inversed axis (reported by Dominic Ford, cf. bug #1461513)
      - invalidate axis partitions with a single label only by the distance rater
      - fallback (with warning) to linear partitioner on a small logarithmics scale
    - painter module:
      - patch to allow for tickattrs=None (reported by Wojciech Smigaj, cf. patch #1286116)
  - color module:
    - transparency support (PDF only)
    - conversion between colorspaces
    - nonlinear palettes added
    - the former palette must now be initialized as linearpalette
    - remove min and max arguments of palettes
  - text module:
    - improve escapestring to handle all ascii characters
    - correct vshift when text size is modified by a text.size instance
    - recover from exceptions (reported by Alan Isaac)
    - handle missing italic angle information in tfm for pdf output (reported by Brett Calcott)
    - allow for .def and .fd files in texmessage.loaddef (new name for
      texmessage.loadfd, which was restricted to .fd files)
  - path module:
    - correct closepath (do not invalidate currentpoint but set it to the
      beginning of the current subpath); structural rework of pathitems
    - calculate real bboxes for Bezier curves
    - fix intersection due to non-linear parametrization of bezier curves
    - add rotate methods to path, normpath, normsubpath, and normsubpathitems
    - add flushskippedline to normsubpath
    - add arclentoparam to normsubpath and normsubpathitems
    - path is no longer a canvasitem
    - reduce number of parameters of outputPS/outputPDF methods (do not pass context and registry)
  - normpath module:
    - contains normpath, normsubpath and normpathparam which have originally
      been in the path module
    - return "invalid" for certain path operations when the curve "speed" is
      below a certain threshold
    - normpath is no longer a canvasitem
    - reduce number of parameters of outputPS/outputPDF methods (do not pass context and registry)
  - deformer module:
    - rewritten smoothed to make use of the subnormpath facilities
    - rewritten parallel for arbitrary paths
  - deco module:
    - add basic text decorator
    - allow arrows at arbitrary positions along the path
  - connector module:
    - boxdists parameter need to be a list/tuple of two items now
    - changed the orientation of the angle parameters
  - trafo module:
    - renamed _apply to apply_pt
    - introduce _epsilon for checking the singularity of a trafo
  - epsfile module:
    - use rectclip instead of clip to remove the clipping path from the
      PostScript stack, which otherwise might create strange effects for
      certain PostScript files (reported by Gert Ingold)
  - dvifile module:
    - silently ignore TrueType fonts in font mapping files (reported by Gabriel Vasseur)
  - type1font module:
    - accept [ and ] as separators in encoding files (reported by Mojca Miklavec, cf. bug #1429524)
  - canvas module:
    - remove registerPS/registerPDF in favour of registering resourcing during the outputPS/outputPDF run
    - move bbox handling to registry
    - rename outputPS/outputPDF -> processPS/processPDF
    - remove set method of canvas
    - add a pipeGS method to directly pass the PyX output to ghostscript
    - allow file instances as parameter of the writeXXXfile methods (feature request #1419658 by Jason Pratt)
  - document modules:
    - allow file instances as parameter of the writeXXXfile methods (feature request #1419658 by Jason Pratt)
  - style module:
    - make rellength the default for dash styles
  - random notes:
    - switched to subversion on 2006/03/09

-- 
by  _ _      _    Dr. André Wobst
   / \ \    / )   wo...@us..., http://www.wobsta.de/
  / _ \ \/\/ /    PyX - High quality PostScript and PDF figures
 (_/ \_)_/\_/     with Python & TeX: visit http://pyx.sourceforge.net/

[PyX-devel] ENABLING WAR: Celebrity Christians and the real Da vinci Code

[<in...@st...>]

Reply-To: cecarl

http://straitgateministry.net/
345-page ONE NATION UNDER ISRAEL Almost FREE (see end)
Published by Truths Press

ENABLING WAR: HOW A BIBLE PUBLISHER CORRUPTED CHRIST'S WORDS
Why Celebrity leaders accept a form of Judaism and call it "Christianity"
By Charles E. Carlson (Director of We Hold These Truths)

This study is not written to convince anyone of what Jesus said; it quotes a small but important part of the Christian New Testament of Jesus, explaining how these words have been reinterpreted to justify serial wars.  This analysis is important to persons of all beliefs, faiths, and races who are trying to understand why wars dominate our world, and why many of those who call themselves by Jesus Christ's name find themselves pitted in support of wars against other races. It is undeniable that our current wars are directed at Islamic populations.  We focus on one bible that is used every day as a war enabler. 

This is a re-written and abbreviated version of our more far reaching 2006 series, "The Sheep and the Goats" Parts 1 & 2, which are drawn from a study of book of Matthew, chapter 25.  Your author is responding to requests that we more clearly prove and document the essence of popular biblical distortion about Heaven and Hell in the book of Matthew. Chapters 24-25, which evangelical believe to contain Jesus' words, are intentionally distorted by these same persons, both in the text and footnotes to the text in most popular bible study versions.

Self professed CHRISTIAN-ZIONISTS at the pulpit of mega-churches are left with an untenable problem. It is impossible for them to tell the truth about what certain New Testament Bible passages say, or even to read them, without contradicting their own support for wars and for the constantly warring state of Israel. Evangelical teaching and preaching often directly contradict that which Jesus taught about love and peace, and more surprisingly, celebrity Christian statements often directly conflict with Jesus' statements about Heaven and Hell. 

Church economics may be a factor in scriptural compromise. Opposition to war is less popular than ignoring or accepting it.  Celebrity Christian leaders may feel financial pressure to warp the New Testament into a wide and easy path interpretation, which they say points, not to Heaven and Hell, but to a "second coming."  Simply stated, pastors have learned they can't fill 10,000 seat arenas by leaning too heavily on sin, repentance and judgment as Jesus portrayed it in this carefully worded chapter. It is just not good for mega-church business.

Nor do they want to refute what is public policy at the highest levels. Some pastors no doubt justify compromise to choose the wide path to build their own empires in contrast to what Christ called the narrow path or "Strait" gate. Our government's public policy includes war, which has also become many churches' policy.

Evangelical celebrities generally believe in politically activism, and every politician knows it pays to be "born again." Thus an unspoken, unholy alliance has been created between financially successful biblical teachers on one hand, and politically successful politicians and businessmen who thrive on serial wars, on the other. The cost has been untold lives in several unholy wars in the 20 years.   But where to the war-accepting pastors find their scriptural support for war? We will examine only once example in a corrupted version of the book of Matthew, in one corrupted bible the Scofield Reference Bible 1967 version.

Oh that my adversary would write a book

The famous Scofield Reference Bible, perhaps the most powerfully promoted Bible ever written, is the godfather of modern bible distortion, which is now emulating and even exceeding in radicalism by other popular study bibles including the NIV Study Bible and the MacArthur Study Bible.   

Matthew 25 contains one of the most directly written and clearly self-explained passages on Heaven and Hell, which was once taken at face value in most churches. But the explanation of Matthew 25 we find so simple and straight forward is now rejected in almost every evangelical (Christian Zionist) church. And the Oxford/Scofield re-write is increasingly influential in a growing number of mainline churches where are members attend dispensational bible studies, and while there hours before celebrity-Christian media.  Members of most Catholic or mainline protestant church are also deeply influenced by the “end times controversy.

Matthew, the first book in the New Testament, contains the most outrageous example of added words that directly contradicts Jesus words. A quote from the Scofield Reference Bible footnotes directly contradicts what Jesus Christ is quoted to have said, His simple words, taken from the King James Edition, describing the basis upon which Jesus told his followers He himself will someday judge every man from every tribe ("nation").  We start by reading Jesus' words in Matthew 25:31-35:

"When the Son of man shall come in his glory, and all the holy angels with him, then shall he sit upon the throne of his glory: 32 And before him shall be gathered all nations: and he shall separate them one from another, as a shepherd divided his sheep from the goats: 33 And he shall set the sheep on his right hand, but the goats on the left. 34 Then shall the King say unto them on his right hand, Come, ye blessed of my Father, inherit the kingdom prepared for you from the foundation of the world: 35 For I was an hungered, and ye gave me meat: I was thirsty, and ye gave me drink: I was a stranger, and ye took me in: (skip to40)---Verily I say unto you, Inasmuch as ye have done it unto one of the least of these my brethren, ye have done it unto me."

The next five versus describe Jesus' rejection of the "goats," those who have been less than kind to the least of "his brethren," judging them unfit for heaven by the same measure.  Jesus provides a standard for his eternal kingdom, simple measurement of faith, love and service, a simple set of rules for His acceptance. 

Now, we must beg your patience to wade through a long paragraph which is a footnote to this same passage in Matthew above, and which footnote directly conflicts with what Jesus taught. Be patient if at first reading you should be confused. From the Scofield (Oxford) Reference bible, 

Matthew 25:32: p-1036-37: 
"This judgment of individual Gentiles is to be distinguished from other judgments in Scripture, such as the judgment of Israel, and the judgment of the wicked after the millennium. The time of this judgment is "when the Son of man shall come in his glory," i.e. at the second coming of Christ after the tribulation. The subjects of this judgment are ...all Gentiles then living on earth. Three classes of individuals are mentioned: (1) sheep, saved Gentiles; (2) goats, unsaved Gentiles; and (3) brethren, the people of Israel. The scene is on earth;...The test of this judgment is the treatment by individual Gentiles of those whom Christ calls "my brethren," living in the preceding tribulation period when Israel is fearfully persecuted...The sheep are Gentiles saved on earth during the period between the rapture and Christ's second coming to the earth..." 

What is that all about? Maybe you need to pinch yourself and read it again. The brethren are "the people of Israel?" but Israel can only mean the state by that name in 1967 when this was written, and the State of Israel did not exist when Jesus lived!  

Oxford Press introduces radical racism into its interpolation of Jesus' words by limiting heaven to "Jews" and those non-Jews who are excessively kind to Jews. And the footnotes also claim it is not even Heaven Jesus it talking about. Instead it is an early kingdom that is yet to come...and it has (according to Oxford) nothing to do with the world the Disciples and Jesus lived in!  

In the Scofield/Oxford University Press’s bible interpretation,” the least of these my brethren" are stated to be "Jews" living in the state of Israel at some future age.  In fact, in this passage Scofield/Oxford ignores Heaven exchanges it for an "earthy kingdom" at a future time after an Armageddon event to take place after a "rapture" event followed by a "millennium" event.  This complex and aggressive re-interruption of Jesus' simple words is an insult to any reader's intelligence and a false witness to God himself.  

WHO ARE JESUS BRETHREN?
When Jesus spoke of "his brethren" He was in no way talking about the 1948 created State of Israel. Surely He was referring to his followers who he often pointedly called brothers. And based upon Jesus many consistent statements about loving ones' neighbor, associates, and even our enemies, it is more likely Jesus was thinking of any and all of suffering mankind when he used the term "the least of these my brethren." But we do not try to decide that for you, let the words speak your own discernment. Suffice to say, the New Testament does not read as Oxford Press portrays it. That makes it a giant intentional forgery. 

"Goats," in Jesus simple pastoral analogy, are those who look a lot like sheep but who act differently and have ignored the needs of their fellow men.

But to Scofield/Oxford University Press, the goats are made to be human symbols of Anti-Israel, anti-Semitism.  They are "gentiles" who fail to shelter Israelis at some future time in imagined history. In other words, Oxford Press wants us to believe Jesus was not even talking to his disciples or needy mankind at all, but that he was tossing cute futurist riddles over his followers' innocent heads.  Why would Jesus lecture his disciples about some future generation that his "brethren" would not even comprehend or live to see?  Jesus words were (this writer thinks) relevant to those who followed him and to the questions they asked.  If Jesus did not shoot strait with his own, how can Jesus words be believable to those who try to follow him now?

Jesus left no doubt about his subject. To make sure everyone knows He was talking about, Heaven and Hell, and nothing else, he provides two parables in first half of the same 25th Chapter that he labeled as explaining the kingdom of Heaven ("the kingdom of Heaven is like"). And nowhere in the chapter did Jesus say he was suddenly inclined to change the subject to a "second coming" scene. Had Jesus intended to give a future history lesson it is logical to think he would have said so.  After all, He is the son of God and knew how to dictate a literate paragraph!  But this did not deter Oxford from changing the subject!

Little lies between the lines
Another Forgery is found in Matthew 24 in the Oxford 1967 edition, page 1035, and is part of the sheep and goats forgery.  It is worth a minute or two to see what Jesus was talking about that Oxford Press considered important enough to forge right in front of the world of Bible readers.  Here they did not change the words but refuted that they mean what Jesus said.  In other words Oxford Press says Jesus is wrong.

Jesus was first asked a natural and simple question by an unnamed disciple in the 3rd verse; 
3)"Tell us, when shall these things be.. what shall be the sign of thy coming, and of the end of the world?" 

To Which Jesus Replied: 
34)"Verily (truly) I say unto you, this generation shall not pass, till all these things be fulfilled."

Jesus was answering his youthful and curious followers, telling them certain events would occur before their "generation" is gone, leaving no doubt that he means some of them might live to see much persecution and the temple destroyed, among less easily understood events. One event specifically asked about was Jesus’ predicted discussion of Herod's Temple, where today the Al Aqsa Mosque stands. It turns out the "in this generation" was absolutely right for the Roman as well as Jewish records show the Temple was completely destroyed about 35 years later in 70 AD under the Roman General Titus. 

Now read the Oxford footnote that actually refutes Jesus words:
1(24:34, page 1035) states: 

"The word 'generation' though commonly used in Scriptures of those living at one time, could not here mean those alive at the time of Christ..." 

Obviously, Oxford Press has a problem with Jesus words so it vetoed what Jesus said.  To do this they invented a new definition of "generation" that fit Oxford's idea of an earthly kingdom in Jerusalem in which the present day state of Israelis, chosen of God, and owning the entire Middle East. Oxford fixed the Bible by making a generation as long as they wish it to be, say 3000 years or more.  This of course would make Jesus a liar to his own followers, but Oxford Press, satisfying the interest of World Zionism, does not flinch at doing this.  

WHAT IS OXFORD'S UNIVERSITY PRESS' MOTIVE?
Oxford Press treats Jesus Christ like a public school drop out who cannot express himself or compose a paragraph without Oxford's help. We are supposed to believe that the Scofield bible (written and rewritten by Oxford University Press from 1921 on) is needed to interpret Jesus lack of expression.  It would have us think God is incapable of explaining his purpose on earth.  How insulting to God. Oxford Press and Pharisaic Christian leaders should tremble in fear before a Holy God. 

Jesus was clearly addressing his Disciples in the whole of Chapter 25, and he was telling them about Heaven and Hell and He explained the earthly path to each place. Traditional Christians (as well as Muslims as we understand them) believe Jesus was describing the "narrow path" to heaven. Jesus does not tell us so but we tend to assume this path is also meant for us to follow. 

Most dispensational pastors avoid discussing Matthew 25 as thought they wish it would disappear. To deal with it they have adopted what we call "Scofieldism" to convert this problem into an asset. Scofieldism make no sense as interpreted in the Oxford footnotes except to "dispensationalists" who have built cults around it.  Scofieldism is gushed from the pulpits of the celebrity Christian churches and go out on Christian airwaves to untold millions. As a result, followers of Christ as well as moral but confused Christian drop outs are confused by the simple words Jesus left for us. 

Jesus words are easy to understand, but difficult to follow toward the strait gate. Oxford Press's words are impossible to understand and as hard to remember, but the interpretations are duck soup to follow...they require almost nothing of those who profess to be "born again."

Those who promoted the Oxford University Press bible (Scofield Reference Bibles) invents a wide and easy path to heaven, where hell is only a factor for others, where sacrificial kindness must be shown only to "Jews," and not even now...but later, during a millennial kingdom. Mr. Scofield coined the terms “dispensations” from which we have "Dispensationalism.” It is quite ok to slaughter Arab children and wage the cruelest wars on their parents.  The false interpretation of Jesus words, teaching that Israelis must be loved more than others has made it quite acceptable in dispensational circles to ignore the continuous bombing and starving of  Arabs and Muslims because they are thought to be Israel's enemies.

The amazing paradox about Scofield-dispensationalism is that it is practiced by those celebrity "Christians" who claim they believe that 100% of the Bible is literally true.  Ted Haggard is one.
Barbara Walters interviewed Evangelical mega-church leader on ABC's 20/20, on December 19th, 2005. The subject was Heaven and Hell. Haggard defined "evangelicalism" as three principles that he said evangelicals believe: that Jesus Christ is the son of God; that the Bible is literally true throughout; and that to go to Heaven one must be "born again."  But Haggard teaches Scofieldism.

It should be no surprise if the Zionist leaning, non-Christian Oxford Press would lie to attain a political agenda to control American Christianity. This was its logical purpose in making, selling and promoting tens of millions of Scofield bibles into American Seminaries and church leaders. 

CONCLUSION 
Dispensationalism is Christian-Zionism, which is racism. It requires each follower to acknowledge the lordship of the State of Israel along side of Christ. Their view of salvation is a glittery wide and easy way that that requires loving "Jews" next to loving God, and more than we love others. We have shown this in Part 2, The Sheep and the Goats. 

The immense, indescribable distortion of Jesus Christ's words of which such clear examples are found in Matthew 25, defies imagination in its brazenness and the cruel intent of its Zionist framers. It is used every day in the USA to enable and instigate the brutality falsely called "war" in the Middle East. -

Evangelical celebrities, and all who knowingly go along with the forgery, have the blood of a several racist wars on their hands.  Jesus' true words require that We Hold These Truths confronts pastors and leaders in tens of thousands of churches, as Jesus confronted the chief priests and Pharisees of his day.  Project Strait Gate is our plan to do this. WE Hold These Truths website is there to help you make your own decision.  Perhaps it will be a life changing and lifesaving decision for you.

Other works by this author:
 http://straitgateministry.net (Click: Pharisee Watch/Listen Live)

The Cause of Our Conflicts
Interactive audio-video presentation (Christian-Zionism's roots)
 
Almost FREE, 345-page ONE NATION UNDER ISRAEL, by Andrew Hurley, the factual documentary in the words of past congressmen telling how AIPAC (American Israeli Public Affairs Committee) has controlled the American Congress for a generation.  Shipping cost only, only one please.  
 
Strait Gate Ministry
Pharisee Watch
PO Box 14491
Scottsdale, AZ 85267
http://straitgateministry.net/

in...@st...
FAX 480 699 1902


To be blocked from future mail, please respond with the word "Delete".
Please write in the Subject line only, (allow one week for change).

[PyX-devel] [ pyx-Feature Requests-1419658 ] write to stdout

[SourceForge.net <no...@so...>]

Feature Requests item #1419658, was opened at 2006-01-31 04:24
Message generated for change (Comment added) made by wobsta
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442889&aid=1419658&group_id=45430

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
Priority: 5
Submitted By: Jason Pratt (pratt)
Assigned to: Nobody/Anonymous (nobody)
Summary: write to stdout

Initial Comment:
It would nice if there were a simple mechanism to write 
documents to stdout instead of a file on the 
filesystem.  

Possible solutions:
--If the filename argument is None for writePDFfile or 
writeEPSfile, write to sys.stdout.
--Have writePDFfile and writeEPSfile take a file 
argument, which defaults to sys.stdout.  This gives the 
added flexibility of using any file handle.
--Create new methods, writePDFToStdout and 
writeEPSToStdout.



----------------------------------------------------------------------

>Comment By: André Wobst (wobsta)
Date: 2006-05-22 19:08

Message:
Logged In: YES 
user_id=405853

I've just implemented suggestion #2 in changeset:2779. Maybe Jörg or 
somebody else might want to comment on that (if necessary), but I wanted to 
get it implemented to have it included in the upcomming release ... so I just 
did it.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442889&aid=1419658&group_id=45430

[PyX-devel] [ pyx-Bugs-1492551 ] keys for histograms

[SourceForge.net <no...@so...>]

Bugs item #1492551, was opened at 2006-05-21 18:57
Message generated for change (Comment added) made by wobsta
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442886&aid=1492551&group_id=45430

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: Dominic Ford (dcf21)
Assigned to: Nobody/Anonymous (nobody)
Summary: keys for histograms

Initial Comment:
In this code snippet (the same one as in bug 1492548),
I also notice that the linestyle of the histogram fails
to appear in the key (I get the title of the dataset,
but no more).

----------------------------------------------------------------------

>Comment By: André Wobst (wobsta)
Date: 2006-05-22 12:34

Message:
Logged In: YES 
user_id=405853

This is a dup of 1371554 and has now been fixed.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442886&aid=1492551&group_id=45430

[PyX-devel] [ pyx-Bugs-1371554 ] Missing `key_pt' method in histogram graph style

[SourceForge.net <no...@so...>]

Bugs item #1371554, was opened at 2005-12-02 10:17
Message generated for change (Comment added) made by wobsta
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442886&aid=1371554&group_id=45430

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Hagemann (mmhagemann)
Assigned to: Nobody/Anonymous (nobody)
Summary: Missing `key_pt' method in histogram graph style

Initial Comment:
When using the histogram graph style, the illustration
of the curve is not shown in the legend.

Fix:  Copying the method from the line style worked for
me.  There may be better alternatives.

I needed this fix to plot many curves as "staircurves"
(for performance plots), using the `steps' parameter. 
In a single histogram, the illustration may be
superfluous, but I think it does not disturb either. 
Omitting the illustration could be made an option in
the `key' class.


----------------------------------------------------------------------

>Comment By: André Wobst (wobsta)
Date: 2006-05-22 12:31

Message:
Logged In: YES 
user_id=405853

You fix is fine. I've applied it to the repo as well.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442886&aid=1371554&group_id=45430

[PyX-devel] [ pyx-Bugs-1492588 ] graph.pos method seems broken

[SourceForge.net <no...@so...>]

Bugs item #1492588, was opened at 2006-05-21 21:07
Message generated for change (Comment added) made by wobsta
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442886&aid=1492588&group_id=45430

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Dominic Ford (dcf21)
Assigned to: Nobody/Anonymous (nobody)
Summary: graph.pos method seems broken

Initial Comment:
The attached code snippet works fine with PyX 0.7.1,
but fails with PyX 0.8.1:

------

Traceback (most recent call last):
  File "pyx_pos.py", line 19, in ?
    x,y = g.pos(x=0,y=0)
  File
"/usr/local/lib/python2.4/site-packages/pyx/graph/graph.py",
line 169, in pos
    return self.xpos + xaxis.convert(x)*self.width,
self.ypos + yaxis.convert(y)*self.height
  File
"/usr/local/lib/python2.4/site-packages/pyx/graph/axis/axis.py",
line 472, in convert
    assert self.canvas is not None, self.errorname
AssertionError: x

------

I believe the cause of this is that the syntax of the
method "convert" has changed in the file
graph/axis/axis.py, but the pos method in the file
graph/graph.py has not been updated to reflect this change.

----------------------------------------------------------------------

>Comment By: André Wobst (wobsta)
Date: 2006-05-22 11:46

Message:
Logged In: YES 
user_id=405853

Sorry, that's not a bug but a problem due to the anchored axes as introduced 
in PyX 0.8 internally. You need to access the axes by g.axes["x"] and 
g.axes["y"], since only by that they have access to the graphs internal data 
(like the axes ranges ... you can use the original axis instances multiple times 
now). Adjusted the manual in changeset:2769.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442886&aid=1492588&group_id=45430

[PyX-devel] [ pyx-Bugs-1492548 ] histograms for negative y-coordinates

[SourceForge.net <no...@so...>]

Bugs item #1492548, was opened at 2006-05-21 18:55
Message generated for change (Comment added) made by wobsta
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442886&aid=1492548&group_id=45430

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Dominic Ford (dcf21)
Assigned to: Nobody/Anonymous (nobody)
Summary: histograms for negative y-coordinates

Initial Comment:
The attached code snippet attempts to plot a histogram
of sin(x). Something seems to go badly wrong when the
function goes negative -- either the left or right
sides of the bars cease to appear.

----------------------------------------------------------------------

>Comment By: André Wobst (wobsta)
Date: 2006-05-22 11:33

Message:
Logged In: YES 
user_id=405853

Thanks for the report. (The vvalue and vfromvalue comparison missed to take 
into account the vfromvalue.) Fixed in changeset:2768.

----------------------------------------------------------------------

Comment By: Dominic Ford (dcf21)
Date: 2006-05-21 19:14

Message:
Logged In: YES 
user_id=1490334

I should add... I'm aware that setting fillable=1 in the
style options fixes this, but as default behaviour, it
doesn't seem so sensible.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442886&aid=1492548&group_id=45430

[PyX-devel] [ pyx-Bugs-1492588 ] graph.pos method seems broken

[SourceForge.net <no...@so...>]

Bugs item #1492588, was opened at 2006-05-21 19:07
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442886&aid=1492588&group_id=45430

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Dominic Ford (dcf21)
Assigned to: Nobody/Anonymous (nobody)
Summary: graph.pos method seems broken

Initial Comment:
The attached code snippet works fine with PyX 0.7.1,
but fails with PyX 0.8.1:

------

Traceback (most recent call last):
  File "pyx_pos.py", line 19, in ?
    x,y = g.pos(x=0,y=0)
  File
"/usr/local/lib/python2.4/site-packages/pyx/graph/graph.py",
line 169, in pos
    return self.xpos + xaxis.convert(x)*self.width,
self.ypos + yaxis.convert(y)*self.height
  File
"/usr/local/lib/python2.4/site-packages/pyx/graph/axis/axis.py",
line 472, in convert
    assert self.canvas is not None, self.errorname
AssertionError: x

------

I believe the cause of this is that the syntax of the
method "convert" has changed in the file
graph/axis/axis.py, but the pos method in the file
graph/graph.py has not been updated to reflect this change.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442886&aid=1492588&group_id=45430

[PyX-devel] [ pyx-Bugs-1492548 ] histograms for negative y-coordinates

[SourceForge.net <no...@so...>]

Bugs item #1492548, was opened at 2006-05-21 16:55
Message generated for change (Comment added) made by dcf21
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442886&aid=1492548&group_id=45430

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Dominic Ford (dcf21)
Assigned to: Nobody/Anonymous (nobody)
Summary: histograms for negative y-coordinates

Initial Comment:
The attached code snippet attempts to plot a histogram
of sin(x). Something seems to go badly wrong when the
function goes negative -- either the left or right
sides of the bars cease to appear.

----------------------------------------------------------------------

>Comment By: Dominic Ford (dcf21)
Date: 2006-05-21 17:14

Message:
Logged In: YES 
user_id=1490334

I should add... I'm aware that setting fillable=1 in the
style options fixes this, but as default behaviour, it
doesn't seem so sensible.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442886&aid=1492548&group_id=45430

[PyX-devel] [ pyx-Bugs-1492551 ] keys for histograms

[SourceForge.net <no...@so...>]

Bugs item #1492551, was opened at 2006-05-21 16:57
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442886&aid=1492551&group_id=45430

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Dominic Ford (dcf21)
Assigned to: Nobody/Anonymous (nobody)
Summary: keys for histograms

Initial Comment:
In this code snippet (the same one as in bug 1492548),
I also notice that the linestyle of the histogram fails
to appear in the key (I get the title of the dataset,
but no more).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442886&aid=1492551&group_id=45430

[PyX-devel] [ pyx-Bugs-1492548 ] histograms for negative y-coordinates

[SourceForge.net <no...@so...>]

Bugs item #1492548, was opened at 2006-05-21 16:55
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442886&aid=1492548&group_id=45430

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Dominic Ford (dcf21)
Assigned to: Nobody/Anonymous (nobody)
Summary: histograms for negative y-coordinates

Initial Comment:
The attached code snippet attempts to plot a histogram
of sin(x). Something seems to go badly wrong when the
function goes negative -- either the left or right
sides of the bars cease to appear.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442886&aid=1492548&group_id=45430

[PyX-devel] [ pyx-Bugs-1429524 ] wrong parsing of .enc files

[SourceForge.net <no...@so...>]

Bugs item #1429524, was opened at 2006-02-11 03:20
Message generated for change (Comment added) made by joergl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442886&aid=1429524&group_id=45430

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: low level PostScript functionality
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Mojca Miklavec (miklavec)
Assigned to: Jörg Lehmann (joergl)
Summary: wrong parsing of .enc files

Initial Comment:
How to reproduce the error?
text.preamble(r"\usepackage{iwona}")

Reason for misbehaviour:
some .enc files may start with something like this:

/enciwona-qx[
/alpha

PyX considers '[' being part of the encoding name and
expects another '[' to appear.

Please also try with
text.preamble(r"\usepackage{lmodern}")

Parsing of .enc files is simple, but yet not as trivial
as it may seem to be.

Mojca

PS: Hoping that PyX will support ConTeXt once as well,
not only (hardcoded) LaTeX;
www.pragma-ade.com/overview.htm. But PyX seems to be
great anyway.


----------------------------------------------------------------------

>Comment By: Jörg Lehmann (joergl)
Date: 2006-05-20 11:35

Message:
Logged In: YES 
user_id=390410

I'm marking this bug as fixed and close it. Feel free to
reopen it again, if the problem has not been fixed.

    Jörg

----------------------------------------------------------------------

Comment By: Jörg Lehmann (joergl)
Date: 2006-02-25 12:15

Message:
Logged In: YES 
user_id=390410

Hello Mojca,

sorry for my late reply, somehow your response slipped
through my radar. Anyway, could you try again. I'm pretty
sure that both of your problems (with the iwona and the
lmodern package) have been fixed now.

    Jörg


----------------------------------------------------------------------

Comment By: Mojca Miklavec (miklavec)
Date: 2006-02-11 14:36

Message:
Logged In: YES 
user_id=1411306


Which files did you change? Type1font and encoding weren't
changed unless I didn't look close enough.

The problem wasn't solved, but I might have done something
wrong. I'm attaching an example of an encoding file which
might cause problems in addition to "/encodingname[".

Iwona is not that important (just a nice and pretty complete
font), but Latin Modern should slowly replace Computer
Modern and might be of greater importance. For your info
only, not so important for PyX itself.

http://www.ctan.org/tex-archive/fonts/lm/
http://www.cstug.cz/aktivity/2005/lm-at11e.pdf

Thanks for the very fast response.

Mojca

(I understand that ConTeXt is not a priority in any way, I
would also prefer to see other features before this one. In
most cases of typesetting simple labels there is not that
big difference if plain TeX/LaTeX/ConTeXt is used. It was
just a thought ...)


----------------------------------------------------------------------

Comment By: Mojca Miklavec (miklavec)
Date: 2006-02-11 14:36

Message:
Logged In: YES 
user_id=1411306


Which files did you change? Type1font and encoding weren't
changed unless I didn't look close enough.

The problem wasn't solved, but I might have done something
wrong. I'm attaching an example of an encoding file which
might cause problems in addition to "/encodingname[".

Iwona is not that important (just a nice and pretty complete
font), but Latin Modern should slowly replace Computer
Modern and might be of greater importance. For your info
only, not so important for PyX itself.

http://www.ctan.org/tex-archive/fonts/lm/
http://www.cstug.cz/aktivity/2005/lm-at11e.pdf

Thanks for the very fast response.

Mojca

(I understand that ConTeXt is not a priority in any way, I
would also prefer to see other features before this one. In
most cases of typesetting simple labels there is not that
big difference if plain TeX/LaTeX/ConTeXt is used. It was
just a thought ...)


----------------------------------------------------------------------

Comment By: Jörg Lehmann (joergl)
Date: 2006-02-11 13:30

Message:
Logged In: YES 
user_id=390410

Hi Mojca,

I checked in a fix. Could you maybe checkout the CVS
version of PyX and try whether it fixes the problem. I 
neither have the iwona package nor, as it seems, the fonts
for the lmodern package installed.

Thanks,
    
    Jörg

PS: With respect to ConTeXt support, I have to say that
adding this, is not a priority for us, since neither of
the developers is a ConTeXt user.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442886&aid=1429524&group_id=45430

[PyX-devel] licensing question

[Alan G I. <ai...@am...>]

Everyone who writes code is entitled to choose their 
license. Of course.

I use two Python graphics packages, both of which are lovely 
and have differing virtues: PyX and Matplotlib.  Both are 
free and open source software, with helpful developers who 
show a sustained commitment to free and open source 
software.  But Matplotlib uses the Python license and PyX 
uses the GPL.

I recently suggested to a Matplotlib developer that 
a certain PyX TeX functionality might synergistically 
combine with some Matplotlib functionality, with two 
benefits:
- Matplotlib would improve its TeX support
- this would potentially increase the total development 
  effort on this part of the code base

The response I got was that the PyX developers have not 
indicated a willingness to license the relevant code under 
the Python license (or another liberal license, such as BSD 
or MIT).

I have mostly a user's perspective, but I have actually 
thought a fair amount about licensing issues.  I cannot see 
a downside for PyX to offering to relicense the relevant 
code; just the opposite in fact.  I am therefore posting 
this appeal to the PyX developers to consider whether the 
lack of downsides and the possible advantages of such 
cooperation might not justify relicensing or dual licensing 
the relevant code.

Alan Isaac

PS I am happy to carry messages between lists in hope of 
make headway, if that would be useful.

[PyX-devel] [ pyx-Bugs-1461513 ] logarithmic axes

[SourceForge.net <no...@so...>]

Bugs item #1461513, was opened at 2006-03-30 19:08
Message generated for change (Settings changed) made by wobsta
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442886&aid=1461513&group_id=45430

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Dominic Ford (dcf21)
Assigned to: Nobody/Anonymous (nobody)
Summary: logarithmic axes

Initial Comment:
The attached piece of code attempts to draw a
logarithmic x-axis, going from right to left, between
limits of 1.5e12 and 6e13. PyX doesn't render a
particularly useful axis. (tested using Python 2.4; PyX
0.7.1). Apologies if this has already been fixed in the
most recent version.

----------------------------------------------------------------------

>Comment By: André Wobst (wobsta)
Date: 2006-04-19 11:21

Message:
Logged In: YES 
user_id=405853

Bug. The problem was the range-rating for reversed axes. Fixed in changeset 
2592. Thanks for your report.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442886&aid=1461513&group_id=45430

[PyX-devel] [ pyx-Bugs-1470498 ] please add support for "legend"

[SourceForge.net <no...@so...>]

Bugs item #1470498, was opened at 2006-04-14 21:08
Message generated for change (Comment added) made by wobsta
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442886&aid=1470498&group_id=45430

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: please add support for "legend"

Initial Comment:
Could you please add support for a "legend"
For bar graphs with more than 2 colors a legend is very
important for people trying to understand the graph...


----------------------------------------------------------------------

>Comment By: André Wobst (wobsta)
Date: 2006-04-18 16:35

Message:
Logged In: YES 
user_id=405853

Supplying a graph.key.key() instance to the graph constructor will create 
graph keys. See the piaxis example on http://pyx.sourceforge.net/examples/
graphs/index.html ... it'll work on bar graphs as well.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442886&aid=1470498&group_id=45430

[PyX-devel] [ pyx-Bugs-1470497 ] bar graphs for negative numbers should start from 0

[SourceForge.net <no...@so...>]

Bugs item #1470497, was opened at 2006-04-14 21:05
Message generated for change (Comment added) made by wobsta
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442886&aid=1470497&group_id=45430

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: bar graphs for negative numbers should start from 0

Initial Comment:
In the examples at:
http://pyx.sourceforge.net/examples/bargraphs/index.html

it seems that negative numbers are drawn from the bottom
of the graph.

Usualy in bar graphs, negative numbers are drawn with
the top of the bar at 0 and the bottom at a negative Y
value.
Positive numbers have the bottom at 0 and the top at a
positive Y value.


----------------------------------------------------------------------

>Comment By: André Wobst (wobsta)
Date: 2006-04-18 16:33

Message:
Logged In: YES 
user_id=405853

Using a graph style combination like
[graph.style.barpos(fromvalue=0), graph.style.bar()]
will change that behaviour.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442886&aid=1470497&group_id=45430

[PyX-devel] [ pyx-Bugs-1470498 ] please add support for "legend"

[SourceForge.net <no...@so...>]

Bugs item #1470498, was opened at 2006-04-14 12:08
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442886&aid=1470498&group_id=45430

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: please add support for "legend"

Initial Comment:
Could you please add support for a "legend"
For bar graphs with more than 2 colors a legend is very
important for people trying to understand the graph...


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442886&aid=1470498&group_id=45430

[PyX-devel] [ pyx-Bugs-1470497 ] bar graphs for negative numbers should start from 0

[SourceForge.net <no...@so...>]

Bugs item #1470497, was opened at 2006-04-14 12:05
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442886&aid=1470497&group_id=45430

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: bar graphs for negative numbers should start from 0

Initial Comment:
In the examples at:
http://pyx.sourceforge.net/examples/bargraphs/index.html

it seems that negative numbers are drawn from the bottom
of the graph.

Usualy in bar graphs, negative numbers are drawn with
the top of the bar at 0 and the bottom at a negative Y
value.
Positive numbers have the bottom at 0 and the top at a
positive Y value.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442886&aid=1470497&group_id=45430

Re: [PyX-devel] connector changes

[Michael S. <m-s...@us...>]

Hello Michael,

On 03.04.06, Michael J Gruber wrote:
> during my tests for an answer on the pyx-user list I noticed some
> changes in the connector module, svn version over 0.8. I just want to
> make sure they're intentional:
> 
> - orientation of angles changed

Yes. This has been done recently due to requests by users who found
the definiton of the angles inconsistent.

> - boxdists can't be a single number any more, has to be a 2-element list

Has already been introduced into 0.8.1

> Those changes correspond to the new documentation; it might be
> worthwhile to point out that it's changed over 0.8, though.
> 
> In particular, the connector example would need different signs in order
> to reproduce the same picture as before (see below).

Thanks for mentioning. I have just checked the changes into svn.

Michael.

-- 
"A mathematician is a device for turning coffee into theorems"
  Paul Erdös.

[PyX-devel] connector changes

[Michael J G. <mic...@fa...>]

Hi guys,

during my tests for an answer on the pyx-user list I noticed some
changes in the connector module, svn version over 0.8. I just want to
make sure they're intentional:

- orientation of angles changed
- boxdists can't be a single number any more, has to be a 2-element list

Those changes correspond to the new documentation; it might be
worthwhile to point out that it's changed over 0.8, though.

In particular, the connector example would need different signs in order
to reproduce the same picture as before (see below).

Cheers,
Michael


for X,Y in [[A, B], [B, C], [C, D], [D, A]]:
    c.stroke(connector.arc(X, Y, relangle=-45, boxdists=[0.2,0.2]),
[color.rgb.red, deco.earrow.normal])

c.stroke(connector.curve(D, B, boxdists=[0.2,0.2], relangle1=-45,
relangle2=-45, relbulge=0.8),
         [color.rgb.blue, deco.earrow.normal])

[PyX-devel] [ pyx-Bugs-1461513 ] logarithmic axes

[SourceForge.net <no...@so...>]

Bugs item #1461513, was opened at 2006-03-30 17:08
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442886&aid=1461513&group_id=45430

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Dominic Ford (dcf21)
Assigned to: Nobody/Anonymous (nobody)
Summary: logarithmic axes

Initial Comment:
The attached piece of code attempts to draw a
logarithmic x-axis, going from right to left, between
limits of 1.5e12 and 6e13. PyX doesn't render a
particularly useful axis. (tested using Python 2.4; PyX
0.7.1). Apologies if this has already been fixed in the
most recent version.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442886&aid=1461513&group_id=45430

Re: [PyX-devel] Suggestion: deco.curvedtext()

[Michael J G. <mic...@fa...>]

Joerg Lehmann venit, vidit, dixit 2006-03-16 17:43:
> Hi Michael,
>=20
> On 16.03.06, Michael J Gruber wrote:
>> I'm kinda getting to like the deco concept... I remembered an old post
>> by Andre, showing a method (due to J=F6rg, I think) for laying out tex=
t
>> along a curve. I adjusted it to the current API and coded it as a
>> decorator dubbed deco.curvedtext(). I'm attaching a simple example (ho=
w
>> to achieve typical line ups) and the code. The code goes into deco.py
>> (current svn). I'm unsure about the following:
>=20
>> a) Is the patch to dvifile.dvifile.putchar appropriate for going into
>> the trunk, or are there side effects (I don't know that module)?
>=20
> No, in this form it's not appropriate because this means that we adjust
> the position after each character, which is rather inefficient.
> The correct way would be to either add an option to the texrunner or
> to allow switching of the single char mode on and off in a dynamical
> way, such that you can request this feature for only parts of the
> output.

I see. It can't be a "set" option either because TeX might be running
already, and it should still be able to change the option. I implemented
a workaround, but I don't know how you think about changing class
variables from the outside...

...
>> sys.path.insert(0, os.environ.get("HOME")+"/lib/python/PyX-svn")
>=20
> Just a side remark: There is os.path.expanduser which allows you to
> just write os.path.expanduser("~/lib/...")

Not much shorter, but nicer.

>>         for op in t.dvicanvas.items:
>>             if isinstance(op, type1font.text_pt):
>>                 x =3D textpos + unit.t_pt*(op.x_pt+op.width_pt/2) # Ma=
ke sure we rotate with respect to the middle of the character.
>>                 op.x_pt =3D  -op.width_pt/2
>>                 c.insert(op, [dp.path.trafo(x)])
>>             else:
>>                 c.insert(op)
>=20
> My latest version looked like:
>=20
>     items =3D t.dvicanvas.items
>     xs =3D [item.bbox().center()[0] for item in items]
>     trafos =3D p.trafo(xs)
>     for x, op, atrafo in zip(xs, items, trafos):
>         c.insert(op, [atrafo, trafo.translate(-x, 0)])
>=20
>>         dp.ornaments.insert(c)

Maybe not shorter, but definitely more pythonish! Also, it's good to
avoid isinstance(). But is this code really more efficient than having
one loop running through all op? It seems we have two list
comprehensions plus one loop now instead of the single loop before.

So, here comes the diff.

Cheers,
Michael

Re: [PyX-devel] Suggestion: deco.curvedtext()

[Joerg L. <jo...@us...>]

Hi Michael,

On 16.03.06, Michael J Gruber wrote:
> I'm kinda getting to like the deco concept... I remembered an old post
> by Andre, showing a method (due to Jörg, I think) for laying out text
> along a curve. I adjusted it to the current API and coded it as a
> decorator dubbed deco.curvedtext(). I'm attaching a simple example (how
> to achieve typical line ups) and the code. The code goes into deco.py
> (current svn). I'm unsure about the following:

> 
> a) Is the patch to dvifile.dvifile.putchar appropriate for going into
> the trunk, or are there side effects (I don't know that module)?

No, in this form it's not appropriate because this means that we adjust
the position after each character, which is rather inefficient.
The correct way would be to either add an option to the texrunner or
to allow switching of the single char mode on and off in a dynamical
way, such that you can request this feature for only parts of the
output.

Because the curved-text thing was really more of quick and dirty a hack,
I didn't follow it further. But it's really neat so maybe we should
integrate it in the core.

> b) Is it appropriate to attach eps examples here?

Depends on the size, I would say.

> c) What's the best format for code suggestions? I'd be happy to send
> diffs, but the patch mentioned above made it somehow inconvenient here
> (the "local" patch I'm applying won't be the final form, of course).
> 
> As for the other text decorators (text as it is or (t)text as suggested
> by me recently or text rotated parallel to the curve [tangential
> labels]): I imagine a universal decorator deco.insert() would be best
> which inserts a given canvas at certain points of the path, with or
> without a user specified alignment, with or without rotation with
> respect to the absolute co system or the local path tangent. Then, all
> text decorators (except for deco.curvedtext) would be simple calls to
> deco.insert(text.text(...)). But one could also easily decorate with
> symbols "moving" along the path and such. Please tell me what you think,
> or else I might start hacking away ;)

I like this idea.

> Cheers,
> Michael

> import os,sys
> sys.path.insert(0, os.environ.get("HOME")+"/lib/python/PyX-svn")

Just a side remark: There is os.path.expanduser which allows you to
just write os.path.expanduser("~/lib/...")

> from pyx import *
>  
> c = canvas.canvas()
> 
> R = 1.3 
> p = path.path(path.arc(0,0, R, 0,270)) + path.line(0,-R, R,-R)
> label = (r"\PyX{} is fun. " * 4)[:-1] # chop off last space 
> 
> c.draw(p, [deco.stroked([color.rgb.blue]), deco.curvedtext(label)])
> c.draw(p, [trafo.translate(2.5*R,0), deco.stroked([color.rgb.blue]), deco.curvedtext(label,textattrs=[text.halign.right],relarclenpos=1)])
> c.draw(p.reversed(), [trafo.translate(0, -2.5*R), deco.stroked([color.rgb.blue]), deco.curvedtext(label,textattrs=[text.halign.right],relarclenpos=1)])
> c.draw(p.reversed(), [trafo.translate(2.5*R, -2.5*R), deco.stroked([color.rgb.blue]), deco.curvedtext(label)])
> 
> 
> c.writeEPSfile(__file__[:-3],fittosize=1, paperformat=document.paperformat.A4)


> import dvifile,type1font
> 
> oldputchar = dvifile.dvifile.putchar
> 
> def newputchar(self, char, advancepos=1):
>   oldputchar(self, char, advancepos)
>   self.flushtext()
> 
> dvifile.dvifile.putchar = newputchar
> 
> class curvedtext(deco, attr.attr):
>     """a text decorator for curved text"""
> 
>     def __init__(self, text, textattrs=[], 
>                        relarclenpos=0, arclenfrombegin=None, arclenfromend=None,
>                        texrunner=None):
>         if arclenfrombegin is not None and arclenfromend is not None:
>             raise ValueError("either set arclenfrombegin or arclenfromend")
>         self.text = text
>         self.textattrs = textattrs
>         self.relarclenpos = relarclenpos
>         self.arclenfrombegin = arclenfrombegin
>         self.arclenfromend = arclenfromend
>         self.texrunner = texrunner
> 
>     def decorate(self, dp, texrunner):
>         if self.texrunner:
>             texrunner = self.texrunner
>         import text as textmodule
> 
>         dp.ensurenormpath()
>         if self.arclenfrombegin is not None:
>             textpos = dp.path.begin() + self.arclenfrombegin
>         elif self.arclenfromend is not None:
>             textpos = dp.path.end() - self.arclenfromend
>         else:
>             # relarcpos is used if neither arcfrombegin nor arcfromend is given
>             textpos = self.relarclenpos * dp.path.arclen()
> 
>         c = canvas.canvas()
>         t = texrunner.text(0, 0, self.text, self.textattrs)
>         for op in t.items: # copy over attr ops (colour...)
>             if not isinstance(op, canvas._canvas): # should not occur before ensuredvicanvas
>                 c.insert(op)
> 
>         t.ensuredvicanvas()

This is what I mean with rather hackish...

>         for op in t.dvicanvas.items:
>             if isinstance(op, type1font.text_pt):
>                 x = textpos + unit.t_pt*(op.x_pt+op.width_pt/2) # Make sure we rotate with respect to the middle of the character.
>                 op.x_pt =  -op.width_pt/2
>                 c.insert(op, [dp.path.trafo(x)])
>             else:
>                 c.insert(op)

My latest version looked like:

    items = t.dvicanvas.items
    xs = [item.bbox().center()[0] for item in items]
    trafos = p.trafo(xs)
    for x, op, atrafo in zip(xs, items, trafos):
        c.insert(op, [atrafo, trafo.translate(-x, 0)])

>         dp.ornaments.insert(c)

        Jörg