Python version
Which version of python is distributed with a new plucker release? The reason I'm asking is that there have been some improvements in the web libraries - and more are planned for 2.4. I'm trying to figure out what baseline I can work with, and what I have to override, just in case. I do not want to override any more than I need to, because then plucker never gets the advantage of python bugfixes and enhancements. (Example: Plucker overrides sgmllib.attrfind. At one point, there were several bugs in the python version. Plucker fixed one -- but python has since fixed that one and several others to boot. Plucker did not get these fixes, because of the override.) Possibilities: (1) The CVS version of the newest stable branch. This includes patches for bugfixes, which might be very minor. (2) The last packaged version of the stable branch. This is currently 2.3.2. The .2 indicates some patches, but not everything was important enough to trigger a release. (3) Some good enough version, such as 2.1 (or, previously, 1.5). (4) Something else, like a custom build? ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
vfs font support
I think I'm going to add VFS font support. A full anti-aliased font package can be enormous. It should be pretty easy to add the support. Any thoughts? -- Dr. Alexander R. Pruss Department of Philosophy Georgetown University Washington, DC 20057-1133 U.S.A. e-mail: [EMAIL PROTECTED] online papers and home page: www.georgetown.edu/faculty/ap85 -- Philosophiam discimus non ut tantum sciamus, sed ut boni efficiamur. - Paul of Worczyn (1424) ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: vfs font support
Alexander R. Pruss wrote: I think I'm going to add VFS font support. A full anti-aliased font package can be enormous. It should be pretty easy to add the support. Any thoughts? -- Sounds like a good idea, if compactness can be done. I put some aa fonts on my T|T device this past week. Looking great! Best wishes, Robert ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: Python version
Hi Jim, I can help provide some info about Python versions. There is no python distributed with either the Mac OSX nor Linux distributions. As of Mac OS X version 10.2 (Jaguar), OS X ships with python as part of the OS. It is python version 2.2, and IIRC is customized to work fast on that OS. Since the python is part of the OS, the OS X Plucker package is a small download. Most people with OS X don't want the parts of their OS to be changed by applications. This is why the OS X Plucker package keeps a PIL (Imaging library) that I custom compiled, inside the Plucker.app folder and runs out of there instead of dropping things over the system directories. Many Linux distributions either have python as part a default install, or as an option during install. The version numbers slowly advance over time as people upgrade their systems. The python version included in the Windows distribution is 2.1.3. Moving from python 1.5 to 2.1 a few years back was needed because of some otherwise unresolvable bugs. There was some slowdown in startup time because of all the new libraries to load in the 2.1 install, that aren't needed by Plucker, such as tcl/tk support and XML. And all of those extra bits need to be shipped in the download, as the python.exe won't open without those libraries being included. A custom compile of python with the compilation switches set to not include some of the big unneeded libraries would be very helpful, in both speeding performance and reducing download/install size. Python is not encumbered by a company owning and preventing custom distributions, so you can compile a speedy version and not only ship it with Plucker, but also make that custom compile available to the larger community as a separate standalone python package that is built for compact size and speedy performance. Best wishes, Robert (2) The last packaged version of the stable branch. This is currently 2.3.2. The .2 indicates some patches, but not everything was important enough to trigger a release. (3) Some good enough version, such as 2.1 (or, previously, 1.5). (4) Something else, like a custom build? ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
www.plkr.org
What happened to the web site? Are the servers down, or moved? Thanks ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: Python version
As of Mac OS X version 10.2 (Jaguar), OS X ships with python as part of the OS. It is python version 2.2, and IIRC is customized to work fast on that OS. As of Mac OS X 10.3 (Panther) it's Python 2.3. Bill ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: www.plkr.org
Seems to be back up. At 09:11 AM 4/12/2003, John Pywtorak wrote: What happened to the web site? ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: vfs font support
Here are some thoughts. Scanning for fonts on VFS is time consuming. One could do it with no real extra time penalty, however, if one did it at the same time as scanning VFS for Plucker documents. But such scanning doesn't always happen--it only happens when one is in the library, and not always then. I don't want to have a slow start-up time if the prefs are set to use a font from VFS. In other words, I don't want to have to do an extra scan of VFS directories to find that font. Currently, the prefs only store the db name for the font, which isn't enough information to retrieve it quickly. One thing I could do is additionally store in the prefs a small cache of the pathnames and volumeRefs of the last three, say, VFS-based font packages used. If the document uses one of these, and the font is still at that location, all is well. But of course it might not be (volumeRefs aren't perfectly stable, and the font may have been moved). If not, then we can do the full scan of VFS directories for all fonts. So my idea is this. Only trigger a separate full scan of VFS directories for fonts when needed. If we can find the font via the cached pathname and volumeRef, all is well. If we are in the library and doing a scan of VFS for Plucker documents, we might as well scan for fonts at the same time. And if a scan of VFS directories for fonts hasn't happened yet by the time the fontform is popped up, then it has to be done then--there is no question about it. Alex ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: vfs font support
On Wed, Dec 03, 2003, Alexander R. Pruss wrote: thing I could do is additionally store in the prefs a small cache of the pathnames and volumeRefs of the last three, I don't think it's a good idea to store the volumeRefs; it's safer to store the volume label and then get the volumeRef using the FindVolRefNum in vfsfile.c. /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
