Got the kinks out of the listing plugin so that it loads and runs correctly from Platypus.jar.
This required updating the manifest to reflect the class-path. Tested and verified.
Pleased to be able to include the listing plugin in the v. 0.2.0 release!
It now does all the steps indicated in previous post correctly.
Also fixed how -fontlist is called, so that it does not depend on PDF plugin.
To do: Create the README file, which will be one of the last things done before the release of v. 0.2.0 RC 1
Handled all steps in previous post but creation of the README file. That will come later as everything is finalized.
Removed the code that necessiated the -Dsun.lang.ClassLoader.allowArraySyntax=true switch due to a bug in JDK 1.6 (See http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6434149)
TO DO:
Building the .zip file and running strictly from the jar file highlighted some defects that need to be worked out.
- The first is that -fontlist can’t find the Start class in the PDF plugin
- The listing plugin also has a class definition error
- I think I need to search /lib in PLATYPUS_HOME and put all the JAR files on the classpath. This should solve 90% of the problems.
- In addition, I think the manifest of each plugin should state where the Start class is found. This allows it to be anywhere in the jar.
The original problem has been fixed. The class files are now copied by Ant into a temp directory using the correct directory hierarchy and the JAR for the plugin is built from that.
Added the Sun Java 1.6 switch to the command line to side step a classloader bug:
-Dsun.lang.ClassLoader.allowArraySyntax=true to command line
To finish the Ant file:
1) delete the build directory used above to create the plugin JAR
2) copy free fonts to the font directory
3) create the batch or shell script
4) create the README file
5) create the .zip file comprising all the other files
Need to do automated testing outside of the IDE, so creating a new Ant file to do the entire build (but just the build. The testing, Javadoc, reports, etc., are run separately).
Printing macros is done with the [* command. So, if XYZ is a macro meaning “hello!”, then [*XYZ] prints “hello!”
Works correctly. But realized that definition of macros has to be passed through to the plugin. Currently, it’s incorrectly being done by the Platypus parser, which does the macro definition operation at parse time.
And then unit tests.
Added the very basic support for the scripting language, which is Groovy.
Loaded the Groovy scripting engine successfully and ran a single-line Groovy script with no difficulty.
Scripts will go between these command markers: [@: and @]
Everything in between is passed to the Groovy engine.
To do:
-Create command class for [@:
-Handle multiline Groovy scripts
-Pass in values to the scripts
-Get values back
Wrote numerous tests for the [def: command and made corrections to the defects revealed by the tests.
Next up: handle the [* command, which prints the contents of the macro.
Can now define the user strings (macros) with [def:macroName{subsituteString}]
Next step: implement the [* command to print the macros
Began migrating the user-string capability, which for the nonce is a one-pass string substitution. As yet, no parameters or multiple levels of macros. Those features will definitely appear in a future release.
Ported the default footer processing from v. 0.1.6.x. It now defaults to a footer that prints a page number with an em-dash and space on either side of the digits in the lower right corner of the page. By default, the footer is printed on all pages except page 1.
Added two commands:
[-footer], which disables printing of the footer
[+footer], which enables printing of the footer
Tip: To have the footer print on page 1 (and all subsequent pages), insert the [+footer] command before the end of the text on page 1. Rather than guess, it’s easier to place it before any text.
Strikethrough (
like this) capability ported from v. 0.1.6.x and works correctly.
URL: http://code.google.com/p/platypus/
This is being used on a test basis, so I can track the status of items (enhancements and defects) in the lead up to release of v. 0.2.x of Platypus.
In addition, this gives me an opportunity to assess Google Code as a future home for the project.
The current project, hosted on Tigris.org, is where defects and enhancements found in shipped releases are logged.
The escape char / in the sequence /[ indicates that the [ is not the opening of a command, but a text character. The / was, in some cases, being passed through to PDF files. That’s been fixed.
Added capability to specify symbols by their Unicode-assigned values. Should make it easier to enter many of the more complex symbols.
To fix: /[xyz] still prints the leading /, even though it’s an escape character.