foray-developer — Discussion list for developers and contributors.

Re: [FOray-developer] PANOSE patch

[Victor M. <vi...@ou...>]

Hi Jason: 

> Here are two more references which may be of interest to you:
> 
> http://www.byte.com/art/9405/sec12/art1.htm
> 
> Michael S. De Laurentis, "PANOSE 1.0 Core Mapper Services,"
> Hewlett-Packard Document EWC-93-0023b, Hewlett-Packard Corporation,
> 101 Stewart, Suite 700, Seattle, WA 98101 (1993).
> 
> That second one would be especially good to see, but I can't 
> find it on the web anywhere!

I can't find it anywhere either, but I did look in my new O'Reilly book
"Fonts & Encodings", chapter 11 on font history and classification, which
has a section on Panose-1. It references a "Grey Book" as being
authoritative. It can be found at:
www.fonts.com/hp/panose/greybook
or, apparently the same document at:
www.panose.com
both actually Monotype pages.

> >  I should add some JUnit tests for this class. Do you have 
> some good 
> > test  cases that I could use to develop the tests?
> 
> The best I can offer is a list of fonts on my Vista machine 
> which failed:
> 
>     http://dev.plutext.org/trac/docx4j/ticket/2
> 
> I'm not sure of their provenance; nor have I looked into why 
> the numbers might be wrong.

There is a comment at
http://developer.apple.com/textfonts/TTRefMan/RM06/Chap6OS2.html
that "Additional specifications required for PANOSE to specify non-Latin
character sets." I wonder if someone has extended it on that axis but not
documented it. It is interesting that all of the failures are on contrast
and stroke variation.

> >  Do you have any interest in using FOrayFont as an 
> individual module? 
> > If you  are only using autodetection and Panose 
> comparisons, maybe it 
> > is easier to  patch the two pieces of FOP and FOray 
> together. Would it 
> > make your life  easier if FOray had the autodetection feature?
> 
> At the moment I am using the FOP font package with Panose and 
> a check for embeddability.  But that's the extent of my use of FOP.
> 
> If FOrayFont did everything I wanted (in essence given a font 
> name, provide the ability to use the best matching font on 
> the local system for use via AWT and PDF output), that would 
> be quite attractive.  I do need autodetection, because 
> docx4all installs via Java Web Start, and I can't expect the 
> word processor user to configure fonts.

I'll see what I can do. Also, if you have not done so already, you might
want to subscribe to the foray developer mailing list so that you can
monitor any progress:
http://www.foray.org/dev/index.html#mail

Victor Mote

Re: [FOray-developer] PANOSE patch

[Jason H. <ja...@pl...>]

Hi Victor

>  Third, thank you very much for the patch that you included in the message. I
>  have committed it to the repository, but have made numerous changes since
>  then, documented below. Thanks especially for the link to the "difference"
>  algorithm. I had unsuccessfully looked for that over a year ago.

Here are two more references which may be of interest to you:

http://www.byte.com/art/9405/sec12/art1.htm

Michael S. De Laurentis, "PANOSE 1.0 Core Mapper Services,"
Hewlett-Packard Document EWC-93-0023b, Hewlett-Packard Corporation,
101 Stewart, Suite 700, Seattle, WA 98101 (1993).

That second one would be especially good to see, but I can't find it
on the web anywhere!

>
>  Before further addressing the PANOSE patch, let me answer your question
>  about font autodetection. I have started down that path several times, but
>  always stop short because of 1) the performance implications, and 2) the
>  loss of flexibility. AFAIK, none of our users would use the feature if we
>  had it, because of these issues. However, that doesn't mean that it couldn't
>  be an option.

See further below.

>
>  OK. Here are the changes I made after committing your patch:

<Snip> .. all sounds good.

>  I should add some JUnit tests for this class. Do you have some good test
>  cases that I could use to develop the tests?

The best I can offer is a list of fonts on my Vista machine which failed:

    http://dev.plutext.org/trac/docx4j/ticket/2

I'm not sure of their provenance; nor have I looked into why the
numbers might be wrong.

>
>  Do you have any interest in using FOrayFont as an individual module? If you
>  are only using autodetection and Panose comparisons, maybe it is easier to
>  patch the two pieces of FOP and FOray together. Would it make your life
>  easier if FOray had the autodetection feature?

At the moment I am using the FOP font package with Panose and a check
for embeddability.  But that's the extent of my use of FOP.

If FOrayFont did everything I wanted (in essence given a font name,
provide the ability to use the best matching font on the local system
for use via AWT and PDF output), that would be quite attractive.  I do
need autodetection, because docx4all installs via Java Web Start, and
I can't expect the word processor user to configure fonts.

>
>  Thanks again for your work on this.

Thank you for making FOray available!

kind regards

Jason

[FOray-developer] PANOSE patch

[Victor M. <vi...@ou...>]

Hi Jason:

First, sorry for the slow response. I was out of the office yesterday.

Second, I am changing the Subject on this mail to reflect essentially a new
thread, but am leaving your message intact (see below) since it is
essentially the first message in this new thread.

Third, thank you very much for the patch that you included in the message. I
have committed it to the repository, but have made numerous changes since
then, documented below. Thanks especially for the link to the "difference"
algorithm. I had unsuccessfully looked for that over a year ago.

Before further addressing the PANOSE patch, let me answer your question
about font autodetection. I have started down that path several times, but
always stop short because of 1) the performance implications, and 2) the
loss of flexibility. AFAIK, none of our users would use the feature if we
had it, because of these issues. However, that doesn't mean that it couldn't
be an option.

OK. Here are the changes I made after committing your patch:
1. Some unimportant style changes.
2. Replaced the System.out calls and the validate method with a new validate
method that returns a String containing the error message or null if the
array is valid. The String can then be used by client apps to throw an
Exception (or write to System.out, or whatever). This is more consistent
with our coding standards, but I wanted to still provide you with the
information that you were writing to System.out.
3. Replaced some constants with a new enum of the PANOSE fields. This is
also more consistent with our coding standards, and should give use some
additional flexibility going forward.
4. Removed the MATCH_THRESHOLD constant, as it was not used.
5. Changed the difference() method to accept another Panose instance instead
of a byte[] instance. This allows us to use the same scheme to validate both
arrays.
6. Made the constructor private, and added a public static factory method
which validates the incoming array before creating the instance.
7. Added a byte[] to the difference() method parameters, thus allowing
client apps to adjust the weights used in the internal calculation.
8. The method getPanoseArray now returns a clone of the internal array
instead of the array itself, to protect the internal array contents from
being changed by some other class.
9. Added two getElement methods that return the values of individual array
elements. This is primarily to avoid the cost of the cloning operation if it
is not needed.

Some of these changes are directly related to your patch, but several of
them are just things that I wasn't smart enough to address the last time I
touched this class. Some of these change the API a bit. I think I have
documented them pretty well in the class, so hopefully you will be able to
follow.

I should add some JUnit tests for this class. Do you have some good test
cases that I could use to develop the tests?

Do you have any interest in using FOrayFont as an individual module? If you
are only using autodetection and Panose comparisons, maybe it is easier to
patch the two pieces of FOP and FOray together. Would it make your life
easier if FOray had the autodetection feature?

Thanks again for your work on this.

Victor Mote


> -----Original Message-----
> From: jh...@gm... [mailto:jh...@gm...] On Behalf 
> Of Jason Harrop
> Sent: Saturday, March 08, 2008 6:41 PM
> To: Victor Mote
> Cc: for...@li...
> Subject: Re: [FOray-developer] ant font - currently fails for 
> SVN head?
> 
> >  I have just committed and published some improvements to 
> the "build"
> >  documentation that should help clear this up, making the aXSL 
> > dependency  more clear. I apologize for the inconvenience. 
> Please let 
> > me know if the  build still does not work after including 
> an up-to-date aXSL build.
> 
> Dear Victor
> 
> Thanks very much for you quick reply to my post.
> 
> I can confirm that the build works now following your 
> instructions to use an interim aXSL build.
> 
> I initially came across foray looking to use the Panose 
> information in a true type file to find an appropriate 
> substitute for fonts specified in the font table part of a 
> Microsoft OpenXML WordprocessingML docx document.
> 
> I want to use the substitute font via AWT in docx4all's user 
> interface, and also for XHTML/PDF output as per
> https://xhtmlrenderer.dev.java.net/r7/users-guide-r7.html#xil_32
> 
> I've been using FOP's org.apache.fop.fonts.autodetect package 
> (added May 2007, see 
> https://issues.apache.org/bugzilla/show_bug.cgi?id=41831
> ) to identify locally installed fonts.
> 
> Maybe you'd like to add that to foray?
> 
> Anyway, for now I'm using your Panose.java with the fop fonts package.
> 
> I've made a few changes to Panose.java, including:
> 
> - difference method squares individual values
> 
> - validPanose accepts higher max values where appropriate 
> (see new field validMaxValues)
> 
> Code is below.
> 
> kind regards
> 
> Jason
> 
> 
> /**
>  * A PANOSE classification number.
>  */
> public class Panose {
> 
>     /** Constant indicating the size of the "panose" field, 
> in bytes. */
>     public static final byte ARRAY_SIZE = 10;
> 
>     /** Max difference for it to be considered an acceptable match.
>      *  Note that this value will depend on the weights in the
>      *  difference function.
>      */
>     public static final int MATCH_THRESHOLD = 30;
> 
> 
>     /** The array of PANOSE numbers. */
>     private byte[] panoseArray;
> 
>     // bFamilyType 5
>     // bSerifStyle 15
>     // bWeight 11
>     // bProportion 9
>     // bContrast 9
>     // bStrokeVariatoon 8
>     // bArmStyle 11
>     // bLetterform 15
>     // bMidline 13
>     // bXHeight 7
>     // See http://fonts.apple.com/TTRefMan/RM06/Chap6OS2.html
>     private final static int[] validMaxValues = { 5, 15, 11, 
> 9, 9, 8, 11, 15, 13, 7 };
> 
>     /**
>      * Creates a new Panose instance.
>      * @param panoseArray The array of bytes recording the PANOSE
>      * classification.
>      */
>     public Panose(final byte[] panoseArray) {
>         this.panoseArray = panoseArray;
>     }
> 
>     /**
>      * Returns the array of bytes representing the PANOSE number.
>      * @return The PANOSE array.
>      */
>     public byte[] getPanoseArray() {
>         return this.panoseArray;
>     }
> 
>     /**
>      * Computes the weighted "closeness" of another Panose to 
> this value.
>      * @param panoseDescription An array of Panose values to 
> compare to this.
>      * @return The weighted difference between the two Panose values.
>      * A smaller value indicates that the two values are 
> closer, and a larger
>      * value indicates that they are farther apart.
>      * A return value of {@link Long#MAX_VALUE} indicates 
> that the input was
>      * invalid or that some other aspect of the comparison 
> was invalid.
>      */
>     public long difference(final byte[] panoseDescription) {
>         if (! validPanose(panoseDescription)) {
>             return Long.MAX_VALUE;
>         }
>         /* We don't really know how to do this. Each byte is 
> supposed to have
>          * a weight, and those weights do not appear to be 
> documented anywhere.
>          *
>          * Called "Panose match value" or "PANOSE Matching Heuristic"
>          * - see http://www.w3.org/Fonts/Panose/pan2.html#Heuristic
>          **/
>         long difference = 0;
>         for (int i = 0; i < panoseDescription.length; i++) {
> //            final int digit = panoseDescription.length - i;
> //            final int weight = (int) Math.round(Math.pow(2, 
> digit - 1));
>             final int weight = 1;
> 
>             final int thisDifference = (this.panoseArray[i] - 
> panoseDescription[i]);
>             difference += weight * thisDifference * thisDifference;
>         }
>         return difference;
>     }
> 
>     /**
>      * Tests the validity of a panose description.
>      * @param panoseDescription The panose values to be tested.
>      * @return True for a valid PANOSE description, or false 
> if the input is
>      * null, does not have 10 elements, or any of the 
> elements do not contain
>      * valid ASCII numerals (0 through 9).
>      */
>     public static boolean validPanose(final byte[] 
> panoseDescription) {
>         if (panoseDescription == null) {
>         	System.out.println("null byte[]" );
>             return false;
>         }
>         if (panoseDescription.length != Panose.ARRAY_SIZE) {
>         	System.out.println("Invalid length " + 
> panoseDescription.length );
>             return false;
>         }
>         for (int i = 0; i < panoseDescription.length; i++) {
>             final byte theByte = panoseDescription[i];
>             String s = Byte.toString(theByte);
>             int n = Integer.parseInt(s);
>             if (n < 0) {
>             	//System.out.println("Invalid value (too small) 
> " + theByte + " in position " + i + " of " + 
> toString(panoseDescription) );
>                 return false;
>             }
> 
>             if (n > validMaxValues[i]) {
>             	System.out.println("Invalid value " + n + " > " 
> + validMaxValues[i] + " in position " + i + " of " +
> toString(panoseDescription) );
>                 return false;
>             }
>         }
>         return true;
>     }
> 
>     public String toString() {
>         return toString(this.panoseArray);    	
>     }
> 
>     public static String toString(byte[] panoseArray) {
> 
>         if (panoseArray.length != Panose.ARRAY_SIZE) {
> 
>         	System.out.println("Unexpected length: " + 
> panoseArray.length);
>         }
>     	
>         StringBuilder sb = new StringBuilder(20);
>     	
>         for (int i = 0; i < panoseArray.length; i++) {
>             final byte theByte = panoseArray[i];
> 
>             sb.append(theByte + " ");
>         }
>     	
>         return sb.toString();    	
>     }
> 
> }
> 
> No virus found in this incoming message.
> Checked by AVG Free Edition. 
> Version: 7.5.516 / Virus Database: 269.21.5/1314 - Release 
> Date: 3/5/2008 6:38 PM
>  
> 

Re: [FOray-developer] ant font - currently fails for SVN head?

[Jason H. <ja...@pl...>]

>  I have just committed and published some improvements to the "build"
>  documentation that should help clear this up, making the aXSL dependency
>  more clear. I apologize for the inconvenience. Please let me know if the
>  build still does not work after including an up-to-date aXSL build.

Dear Victor

Thanks very much for you quick reply to my post.

I can confirm that the build works now following your instructions to
use an interim aXSL build.

I initially came across foray looking to use the Panose information in
a true type file to find an appropriate substitute for fonts specified
in the font table part of a Microsoft OpenXML WordprocessingML docx
document.

I want to use the substitute font via AWT in docx4all's user
interface, and also for XHTML/PDF output as per
https://xhtmlrenderer.dev.java.net/r7/users-guide-r7.html#xil_32

I've been using FOP's org.apache.fop.fonts.autodetect package (added
May 2007, see https://issues.apache.org/bugzilla/show_bug.cgi?id=41831
) to identify locally installed fonts.

Maybe you'd like to add that to foray?

Anyway, for now I'm using your Panose.java with the fop fonts package.

I've made a few changes to Panose.java, including:

- difference method squares individual values

- validPanose accepts higher max values where appropriate (see new
field validMaxValues)

Code is below.

kind regards

Jason


/**
 * A PANOSE classification number.
 */
public class Panose {

    /** Constant indicating the size of the "panose" field, in bytes. */
    public static final byte ARRAY_SIZE = 10;

    /** Max difference for it to be considered an acceptable match.
     *  Note that this value will depend on the weights in the
     *  difference function.
     */
    public static final int MATCH_THRESHOLD = 30;


    /** The array of PANOSE numbers. */
    private byte[] panoseArray;

    // bFamilyType 5
    // bSerifStyle 15
    // bWeight 11
    // bProportion 9
    // bContrast 9
    // bStrokeVariatoon 8
    // bArmStyle 11
    // bLetterform 15
    // bMidline 13
    // bXHeight 7
    // See http://fonts.apple.com/TTRefMan/RM06/Chap6OS2.html
    private final static int[] validMaxValues = { 5, 15, 11, 9, 9, 8,
11, 15, 13, 7 };

    /**
     * Creates a new Panose instance.
     * @param panoseArray The array of bytes recording the PANOSE
     * classification.
     */
    public Panose(final byte[] panoseArray) {
        this.panoseArray = panoseArray;
    }

    /**
     * Returns the array of bytes representing the PANOSE number.
     * @return The PANOSE array.
     */
    public byte[] getPanoseArray() {
        return this.panoseArray;
    }

    /**
     * Computes the weighted "closeness" of another Panose to this value.
     * @param panoseDescription An array of Panose values to compare to this.
     * @return The weighted difference between the two Panose values.
     * A smaller value indicates that the two values are closer, and a larger
     * value indicates that they are farther apart.
     * A return value of {@link Long#MAX_VALUE} indicates that the input was
     * invalid or that some other aspect of the comparison was invalid.
     */
    public long difference(final byte[] panoseDescription) {
        if (! validPanose(panoseDescription)) {
            return Long.MAX_VALUE;
        }
        /* We don't really know how to do this. Each byte is supposed to have
         * a weight, and those weights do not appear to be documented anywhere.
         *
         * Called "Panose match value" or "PANOSE Matching Heuristic"
         * - see http://www.w3.org/Fonts/Panose/pan2.html#Heuristic
         **/
        long difference = 0;
        for (int i = 0; i < panoseDescription.length; i++) {
//            final int digit = panoseDescription.length - i;
//            final int weight = (int) Math.round(Math.pow(2, digit - 1));
            final int weight = 1;

            final int thisDifference = (this.panoseArray[i] -
panoseDescription[i]);
            difference += weight * thisDifference * thisDifference;
        }
        return difference;
    }

    /**
     * Tests the validity of a panose description.
     * @param panoseDescription The panose values to be tested.
     * @return True for a valid PANOSE description, or false if the input is
     * null, does not have 10 elements, or any of the elements do not contain
     * valid ASCII numerals (0 through 9).
     */
    public static boolean validPanose(final byte[] panoseDescription) {
        if (panoseDescription == null) {
        	System.out.println("null byte[]" );
            return false;
        }
        if (panoseDescription.length != Panose.ARRAY_SIZE) {
        	System.out.println("Invalid length " + panoseDescription.length );
            return false;
        }
        for (int i = 0; i < panoseDescription.length; i++) {
            final byte theByte = panoseDescription[i];
            String s = Byte.toString(theByte);
            int n = Integer.parseInt(s);
            if (n < 0) {
            	//System.out.println("Invalid value (too small) " +
theByte + " in position " + i + " of " + toString(panoseDescription)
);
                return false;
            }

            if (n > validMaxValues[i]) {
            	System.out.println("Invalid value " + n + " > " +
validMaxValues[i] + " in position " + i + " of " +
toString(panoseDescription) );
                return false;
            }
        }
        return true;
    }

    public String toString() {
        return toString(this.panoseArray);    	
    }

    public static String toString(byte[] panoseArray) {

        if (panoseArray.length != Panose.ARRAY_SIZE) {

        	System.out.println("Unexpected length: " + panoseArray.length);
        }
    	
        StringBuilder sb = new StringBuilder(20);
    	
        for (int i = 0; i < panoseArray.length; i++) {
            final byte theByte = panoseArray[i];

            sb.append(theByte + " ");
        }
    	
        return sb.toString();    	
    }

}

Re: [FOray-developer] ant font - currently fails for SVN head?

[Victor M. <vi...@ou...>]

Hi Jason:

I have just committed and published some improvements to the "build"
documentation that should help clear this up, making the aXSL dependency
more clear. I apologize for the inconvenience. Please let me know if the
build still does not work after including an up-to-date aXSL build.

Victor Mote

[FOray-developer] ant font - currently fails for SVN head?

[Jason H. <ja...@pl...>]

Hi Victor

As pet the subject line, building font from svn head is currently
failing for me.  Amongst other things:

    [javac] /home/jharrop/workspace200711/foray/foray-font/src/java/org/foray/font/FOrayFont.java:376:
cannot find symbol
    [javac] symbol  : class Baseline
    [javac] location: class org.foray.font.FOrayFont
    [javac]             final Baseline baselineType, final int fontSize) {

    [javac] /home/jharrop/workspace200711/foray/foray-font/src/java/org/foray/font/FOrayFont.java:414:
cannot find symbol
    [javac] symbol  : variable ALPHABETIC
    [javac] location: class org.foray.font.FOrayFont
    [javac]         case ALPHABETIC: {

    [javac] /home/jharrop/workspace200711/foray/foray-font/src/java/org/foray/font/SystemFont.java:51:
org.foray.font.SystemFont is not abstract and does not override
abstract method baseline(org.axsl.common.value.Iso15924) in
org.axsl.font.Font
    [javac] public final class SystemFont extends org.foray.font.FOrayFont {

Thought you might like to know.

thanks

Jason

[FOray-developer] FOray 0.3 released

[Victor M. <vi...@ou...>]

Dear Friends of FOray:

I am happy to announce the 0.3 release of FOray, available here:
http://www.foray.org/app/using/download.html

The release notes are here:
http://www.foray.org/00-release/notes-0_003.html

Much of the effort expended in this release related to changes related to
the upgrade to Java 5, javadoc improvements, API improvements, adding
testing infrastructure, and absorbing the XSL-FO 1.1 Recommendation. In
short, much of it benefits the developers and should make future development
easier. Many bugs were fixed, but there are several places where the product
needs serious improvement. I hope to address at least some of these in the
coming months. I hope that the next release will have more improvements for
users (rather than developers).

The future prospects for FOray are good. We have paid the infrastructure
bill and most of the API bill, and should be able to steadily improve the
product from this point forward. We have stronger-than-expected competition
from FOP but are glad for it. Their philosophy excludes use of our efforts,
but our philosophy allows us to benefit from the best of their improvements.

Your comments are welcome.

Victor Mote

[FOray-developer] font locations for aXSL font configuration

[Victor M. <vi...@ou...>]

Hi All:

I just committed a change that improves the integration between the FOray
configuration and the aXSL font configuration. The aXSL font configuration
scheme has the ability to set parameters from the java or system
environment. When used with FOray, the FOray parser now also treats the
special variable FONT_BASE_DIRECTORY (if not found in the environment) as
equal to the "font-base-directory" entry in the FOray configuration. Thus
there is no need to configure an environment variable for this value, as
long as it is configured in the FOray configuration. Details are here:
http://www.foray.org/app/features/fonts.html#config

Victor Mote

[FOray-developer] build environment

[Victor M. <vi...@ou...>]

Hi All:

I changed the build environment today to use the property "foray.sandbox"
where it used to use "foray.home". The distinction between the two is
important in situations where one machine may be used for both development
and production work. So "foray.sandbox" points to the development sandbox,
and "foray.home" is now reserved for production. You will need to change the
"foray.home" entry in your foray-build.properties file accordingly.

I also added a page to the developer section of the web site entitled
"Environment" on the left menu:
http://www.foray.org/dev/env.html
There is some content there now, and I will add to it as I have an
opportunity. Its purpose is to help developers more quickly get a working
FOray development environment set up and productive.

Victor Mote

[FOray-developer] Graphic support

[Victor M. <vi...@ou...>]

Hi All:

I am pleased to announce that FOray no longer has any dependencies on the
Java Advanced Imaging (JAI) system, which has been needed for PNG and TIFF
support. Because of licensing issues, JAI has been a separate download,
which has been an inconvenience for users. Current repository code uses and
future releases will use the Apache XML Graphics Commons library to achieve
the same general effect.

There is still much work to do to improve the FOray Graphics library, but
this step should put us in a better position to do so.

In addition, improvements have been made to the API to clarify the nature of
the image sample data that is returned. JPEG and TIFF formats return their
compressed values, while other formats are converted first to a standard
ordering. Previously these were handled in the same method, but are now
handled in separate methods, so that client applications can (theoretically)
use whichever they need, and to clean up the code behind that logic.

I have also added a suite of functional Graphics package tests into the
JUnit harness to help us manage changes to the Graphics package.
Contributions of non-working files that we can use for testing and
development purposes will be most welcome.

Victor Mote 

Re: [FOray-developer] FOP integration & Java 1.5

[Victor M. <vi...@ou...>]

Hi Vincent: 

> Victor, thanks for you kind words, and sorry for not letting 
> you know about our decision. To be honest I was a bit afraid 
> of your reaction, and I also feel a bit bad that we couldn't 
> find a way to work together.

I think it was a bad decision for FOP, but it is only the latest in a long
string of them, and I have grown accustomed to them. The creation of FOray
allowed me to move on, not worry about FOP's decisions, and just get my work
done.

I am sorry that anyone would be afraid of my reaction. And I am even more
sorry if I am perceived as being difficult to understand or work with. You
are right that there *are* some cultural differences at work. But more than
that I see two things:
1. The one issue that I remember where we struggled to understand each other
was the URL protocol issue. That problem is really intractable in any clean
way. So we were left with a situation where we needed to choose which ugly
way to handle it, and ultimately figured out a way to let everybody choose
which ugly way they preferred. So, while I regretted the amount of time it
took to address (my time is valuable too), I was glad we were eventually
able to make everyone happy, and I think we solved it in a way that we
shouldn't ever have to address it again. So I thought we did OK considering
the complexity of the issue.
2. There is another factor here that I hate to admit. I am not new to
software development, but I am newer to Java than most of the guys working
on FOP, and I am totally self-taught on Java. So frankly, most of you are
probably better Java developers than I am, or at least than I was when I was
working on that project. So sometimes an issue that is clear enough to you
might escape me entirely. A pretty good example was your concern about
catching Errors and unchecked Exceptions. I understand your concern better
today than I did when we last discussed it.

So, in light of #2, one might think I should be more humble and just submit
to the decisions of wiser or smarter people. And indeed, I make a conscious
effort to give due respect to them. It seems to me that two people looking
at things from opposite angles can, with the effort and pain that you have
described, come up with something that is better than either one of them
would have achieved by themselves.

The flip side of that is that there are principles of software development
that transcend Java or even object-oriented programming, that FOP has
abandoned, for no good reason, at least none that anyone has been able to
cogently explain. The fact that a bunch of smart people working together
don't see it is perhaps a sign of youth and inexperience, or, as I currently
think, inbreeding. So, IMO greater respect is due to us old-timers as well.

So, I will miss the invaluable assistance that you and Jeremias have given
-- I have learned to take you guys seriously even when I don't at first
understand your point. And I hope the investment you have made in FOray pays
off in your FOP work.

> It would have probably helped to meet in real life, but 
> things are the way they are.
> It will be interesting to see what both products will 
> achieve. Perhaps we will find a later opportunity to merge 
> back our works. Fonts are definitely not a simple area.

This is a nice sentiment, but I see no hope here. Reunification would
require one of three things: 1) FOray to abandon its modular design, 2) FOP
to spin off modules, or 3) FOP to use external modules. FORay has
emphatically rejected #1, and FOP has emphatically and categorically
rejected #2, and has rejected #3 WRT FOray.

> > WRT FOP code being used in FOray, do not be surprised to 
> see a FOray 
> > line-breaking strategy and layout strategy that is based on 
> the layout 
> > work you guys have done. I haven't actually looked at the code -- I 
> > understand the two are tightly intertwined in the FOP code 
> right now, 
> > and FOray would
> 
> Not so much, actually, apart from a few common super-classes. 
> That said, the code would certainly benefit from some heavy 
> refactoring. Oh, and I've recently started to think that we 
> can achieve even better layout results by actually merging 
> line-level and page-level breaking. But that's another story ;-)

Yes, I have had similar thoughts myself recently. The aXSL interfaces in
both of these systems require some major work.

Vincent, thank you again for your efforts and contributions. If I had two
guys like you working on FOray, we would have this thing working well in
short order. I think very highly of you, and wish you the best. Please let
me know if I can help you in any way.

Victor Mote

Re: [FOray-developer] FOP integration & Java 1.5

[Peter B. W. <li...@pb...>]

Vincent Hennebert wrote:
> 
> Victor, thanks for you kind words, and sorry for not letting you know
> about our decision. To be honest
!!!
 I was a bit afraid of your reaction,

There you have it. It's your fault, Victor.

> and I also feel a bit bad that we couldn't find a way to work together.
> It would have probably helped to meet in real life, but things are the
> way they are.

Greater glory to you Vincent.

Peter
-- 
Peter B. West <http://cv.pbw.id.au/>
Folio <http://defoe.sourceforge.net/folio/>

Re: [FOray-developer] FOP integration & Java 1.5

[Vincent H. <vin...@an...>]

(Sorry for the late answer, for some reason my mail client didn't notify
me of new mails in this folder.)

Victor Mote a =C3=A9crit :
> Hi Jeremias:=20
>=20
>> I'm sure we won't forget each other. You may be able to=20
>> profit from some features in XML Graphics Commons or even FOP=20
>> one day. And maybe we even get back to you at some point=20
>> because of something useful in FOray. I can't get that=20
>> PostScript interpreter out of my mind. :-)
>=20
> I meant to say in my earlier post that we *have* profited from FOP's
> involvement, especially Vincent's work. I think the Font API is much
> stronger now than it was before, largely because of his good input. And=
 I
> think the AWT work that you did on the PostScript interpreter was very
> valuable as a further proof of concept of the design there. (Someday I =
hope
> it will also have a full-blown PostScript-to-PDF transcoder).

Victor, thanks for you kind words, and sorry for not letting you know
about our decision. To be honest I was a bit afraid of your reaction,
and I also feel a bit bad that we couldn't find a way to work together.
It would have probably helped to meet in real life, but things are the
way they are.
It will be interesting to see what both products will achieve. Perhaps
we will find a later opportunity to merge back our works. Fonts are
definitely not a simple area.


> WRT FOP code being used in FOray, do not be surprised to see a FOray
> line-breaking strategy and layout strategy that is based on the layout =
work
> you guys have done. I haven't actually looked at the code -- I understa=
nd
> the two are tightly intertwined in the FOP code right now, and FOray wo=
uld

Not so much, actually, apart from a few common super-classes. That said,
the code would certainly benefit from some heavy refactoring. Oh, and
I've recently started to think that we can achieve even better layout
results by actually merging line-level and page-level breaking. But
that's another story ;-)


I wish you good success.
Vincent

[FOray-developer] Java 1.5

[Victor M. <vi...@ou...>]

Based on the fact that no negative feedback has been received for upgrading
to Java 1.5, and based on the needs of aXSL, which wants to solidify its API
around typesafe enums where that is appropriate, FOray is in the process of
upgrading to Java 1.5. Some changes have already been made to use the new
features, and more will be forthcoming.

Please post a message to the support list
(mailto:for...@li...) if you have any problems with
the upgrade.

Victor Mote

Re: [FOray-developer] FOP integration & Java 1.5

[Victor M. <vi...@ou...>]

Hi Jeremias: 

> I'm sure we won't forget each other. You may be able to 
> profit from some features in XML Graphics Commons or even FOP 
> one day. And maybe we even get back to you at some point 
> because of something useful in FOray. I can't get that 
> PostScript interpreter out of my mind. :-)

I meant to say in my earlier post that we *have* profited from FOP's
involvement, especially Vincent's work. I think the Font API is much
stronger now than it was before, largely because of his good input. And I
think the AWT work that you did on the PostScript interpreter was very
valuable as a further proof of concept of the design there. (Someday I hope
it will also have a full-blown PostScript-to-PDF transcoder).

WRT FOP code being used in FOray, do not be surprised to see a FOray
line-breaking strategy and layout strategy that is based on the layout work
you guys have done. I haven't actually looked at the code -- I understand
the two are tightly intertwined in the FOP code right now, and FOray would
need to pull them apart, which may be a lot of trouble. But I have high
hopes that it will be possible. I do think the general approach that you and
Luca took is right.

Victor Mote

Re: [FOray-developer] FOP integration & Java 1.5

[Jeremias M. <de...@je...>]

Hi Victor

On 29.01.2007 18:03:18 Victor Mote wrote:
> Hi Jeremias:=20
>=20
> > Sorry, Victor, for not actively informing you. We've discussed it in=20
> > October/November and finally decided not to pursue this course. Please=
=20
> > find the details of our discussion here:
> > http://www.nabble.com/FOrayFont-integration-in-question-tf2622698.html
>=20
> OK. Thanks for the update. That will help FOray with its planning. I read
> the whole thread. I think Vincent's comments were very fair. I do regret
> that we can't find a way to work together. I also feel bad about the
> perception that it would be a large time investment to try to work togeth=
er.
> However, I understand it -- I am quite sure that I am (without exaggerati=
on)
> 50 times as productive as I was when I was working on FOP -- it seemed
> impossible to get anything done without talking about it a lot.
>=20
> I definitely understand the concern about being a one-man show. That has
> never been my intent, but that does seem to be the way it is. If I had
> involved with that conversation, I would have pointed out that working wi=
th
> a one-man show is less of a risk than some Foppers seem to think -- If yo=
u
> don't like the direction the project is going, you just fork it then. No =
big
> deal. But that is water under the bridge.

Of course, forking would have been possible. But given the ASF's
licensing policy this would not be so easy. We would still have to ask
you for a grant or to do the actual fork in our own codebase under your
ICLA but the latter is definitely weird. :-)

> > Sorry for the probably bad news. And thank you for your willingness to=
=20
> > help us. I hope that the input from the FOP side still helped FOray in=
=20
> > certain areas and not all effort on your part was in vain.
>=20
> The news is part good, part disappointing. It does liberate us a bit. I
> think each party has well and truly considered the other's point of view,
> and decided that it is in fact easier to duplicate effort than to work
> together. It is good that we have the freedom to make those choices. I lo=
ok
> forward to seeing who gets the job done best and fastest. To a large exte=
nt
> we are developing entirely different products, so perhaps there will neve=
r
> be a definitive answer anyway. I wish FOP well. Please let us know if the
> there is anything FOray can do to help.

I'm sure we won't forget each other. You may be able to profit from some
features in XML Graphics Commons or even FOP one day. And maybe we even
get back to you at some point because of something useful in FOray. I
can't get that PostScript interpreter out of my mind. :-)

All the best to Foray, too. Diversity and choice are good things.

> > BTW, I'd do careful testing on JRE 1.4 if you're developing on JDK=20
> > 1.5.
> > After all, JDK 1.5 got a few new features in the class library that=20
> > won't be available in JRE 1.4 even if the byte code is compatible with=
=20
> > a
> > 1.4 VM. Otherwise, you might exclude a big set of potential users.=20
> > Many companies are still actively developing on 1.4.
>=20
> Yea. The whole idea has always made me nervous, but I haven't actually tr=
ied
> it. Thanks for the advice.
>=20
> Victor Mote
>=20
>=20
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share y=
our
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D=
DEVDEV
> _______________________________________________
> FOray-developer mailing list
> FOr...@li...
> https://lists.sourceforge.net/lists/listinfo/foray-developer



Jeremias Maerki

Re: [FOray-developer] FOP integration & Java 1.5

[Victor M. <vi...@ou...>]

Hi Jeremias: 

> Sorry, Victor, for not actively informing you. We've discussed it in 
> October/November and finally decided not to pursue this course. Please 
> find the details of our discussion here:
> http://www.nabble.com/FOrayFont-integration-in-question-tf2622698.html

OK. Thanks for the update. That will help FOray with its planning. I read
the whole thread. I think Vincent's comments were very fair. I do regret
that we can't find a way to work together. I also feel bad about the
perception that it would be a large time investment to try to work together.
However, I understand it -- I am quite sure that I am (without exaggeration)
50 times as productive as I was when I was working on FOP -- it seemed
impossible to get anything done without talking about it a lot.

I definitely understand the concern about being a one-man show. That has
never been my intent, but that does seem to be the way it is. If I had
involved with that conversation, I would have pointed out that working with
a one-man show is less of a risk than some Foppers seem to think -- If you
don't like the direction the project is going, you just fork it then. No big
deal. But that is water under the bridge.

> Sorry for the probably bad news. And thank you for your willingness to 
> help us. I hope that the input from the FOP side still helped FOray in 
> certain areas and not all effort on your part was in vain.

The news is part good, part disappointing. It does liberate us a bit. I
think each party has well and truly considered the other's point of view,
and decided that it is in fact easier to duplicate effort than to work
together. It is good that we have the freedom to make those choices. I look
forward to seeing who gets the job done best and fastest. To a large extent
we are developing entirely different products, so perhaps there will never
be a definitive answer anyway. I wish FOP well. Please let us know if the
there is anything FOray can do to help.

> BTW, I'd do careful testing on JRE 1.4 if you're developing on JDK 
> 1.5.
> After all, JDK 1.5 got a few new features in the class library that 
> won't be available in JRE 1.4 even if the byte code is compatible with 
> a
> 1.4 VM. Otherwise, you might exclude a big set of potential users. 
> Many companies are still actively developing on 1.4.

Yea. The whole idea has always made me nervous, but I haven't actually tried
it. Thanks for the advice.

Victor Mote

Re: [FOray-developer] FOP integration & Java 1.5

[Victor M. <vi...@ou...>]

Hi Max: 

> Not necessarily. You have the "-target" and "-source" flags, which you 
> can use to specifically mention which jvm to compile for. For example, 
> I usually use jdk 1.5, but usually all my code is compiled with 
> "target" and "source" of 1.4.
> 
> Unfortunately, if you want to use the cool new language features of 
> 1.5, then you have to set both, target and source, to 1.5. At least 
> suns java compiler does not allow you to use the 1.5 language features 
> without requiring the 1.5 jvm.
> 
> I would recommend to add the "target" and "source" flags to the 
> compilation process, no matter what you decide. This makes it more 
> clear.

Thant makes sense. Thanks for the input.

Victor

Re: [FOray-developer] FOP integration & Java 1.5

[Max B. <ma...@be...>]

Victor,

Am Sonntag, 28. Januar 2007 20:40 schrieb Victor Mote:
> 2. I am also under the impression that FOP may move to Java 1.4 in the ne=
ar
> future. It is my understanding that code compiled on Java 1.5 compilers
> runs properly on Java 1.4 runtimes.=20

Not necessarily. You have the "-target" and "-source" flags, which you can =
use=20
to specifically mention which jvm to compile for. For example, I usually us=
e=20
jdk 1.5, but usually all my code is compiled with "target" and "source" of=
=20
1.4.

Unfortunately, if you want to use the cool new language features of 1.5, th=
en=20
you have to set both, target and source, to 1.5. At least suns java compile=
r=20
does not allow you to use the 1.5 language features without requiring the 1=
=2E5=20
jvm.

I would recommend to add the "target" and "source" flags to the compilation=
=20
process, no matter what you decide. This makes it more clear.

Hope this makes sense

Max

Re: [FOray-developer] FOP integration & Java 1.5

[Jeremias M. <de...@je...>]

Hi Victor

On 28.01.2007 20:40:01 Victor Mote wrote:
> Hi folks:
>=20
> I am considering moving FOray to Java 1.5 for several good reasons. The m=
ain
> reason I have not done so already is because I was trying to prevent us f=
rom
> getting to a place where we were too far away from FOP's platform. Here a=
re
> the considerations:
>=20
> 1. Nobody has said so explicitly, but I am under the impression that FOP =
has
> chosen not to write to the aXSL interfaces, nor to use any of the FOray
> packages. So perhaps my concerns about maintaining code that was usable b=
y
> them were poorly placed. Can anyone shed light on this?

Sorry, Victor, for not actively informing you. We've discussed it in
October/November and finally decided not to pursue this course. Please
find the details of our discussion here:
http://www.nabble.com/FOrayFont-integration-in-question-tf2622698.html


> 2. I am also under the impression that FOP may move to Java 1.4 in the ne=
ar
> future. It is my understanding that code compiled on Java 1.5 compilers r=
uns
> properly on Java 1.4 runtimes. This would mean that developers would need=
 to
> use 1.5 for development and builds, but that users would not be forced to
> use it at runtime. If all of these are true, then FOray could move to 1.5
> with no detriment to FOP anyway. Does anyone know what FOP's intentions a=
re
> in this matter, or care to comment on the assumptions I have made WRT
> 1.4/1.5 compatibility?

It's very likely that we're not going to make any further efforts to
maintain JDK 1.3 compatibility and make 1.4 our dev environment. We
haven't voted on this, yet. And I will want to have a user poll first.
The same question is open for Batik, too.

> Also, if anyone other than FOP has concerns about moving to Java 1.5, now
> would be a good time to raise them.
>=20
> Victor Mote

Sorry for the probably bad news. And thank you for your willingness to
help us. I hope that the input from the FOP side still helped FOray in
certain areas and not all effort on your part was in vain.

BTW, I'd do careful testing on JRE 1.4 if you're developing on JDK 1.5.
After all, JDK 1.5 got a few new features in the class library that
won't be available in JRE 1.4 even if the byte code is compatible with a
1.4 VM. Otherwise, you might exclude a big set of potential users. Many
companies are still actively developing on 1.4.

Jeremias Maerki

[FOray-developer] FOP integration & Java 1.5

[Victor M. <vi...@ou...>]

Hi folks:

I am considering moving FOray to Java 1.5 for several good reasons. The main
reason I have not done so already is because I was trying to prevent us from
getting to a place where we were too far away from FOP's platform. Here are
the considerations:

1. Nobody has said so explicitly, but I am under the impression that FOP has
chosen not to write to the aXSL interfaces, nor to use any of the FOray
packages. So perhaps my concerns about maintaining code that was usable by
them were poorly placed. Can anyone shed light on this?

2. I am also under the impression that FOP may move to Java 1.4 in the near
future. It is my understanding that code compiled on Java 1.5 compilers runs
properly on Java 1.4 runtimes. This would mean that developers would need to
use 1.5 for development and builds, but that users would not be forced to
use it at runtime. If all of these are true, then FOray could move to 1.5
with no detriment to FOP anyway. Does anyone know what FOP's intentions are
in this matter, or care to comment on the assumptions I have made WRT
1.4/1.5 compatibility?

Also, if anyone other than FOP has concerns about moving to Java 1.5, now
would be a good time to raise them.

Victor Mote

[FOray-developer] non-member messages rejected

[Victor M. <vi...@ou...>]

Hi All:

In an attempt to reduce the number of spam messages that must be manually
filtered, I have changed the settings on this list to accept mail only from
those subscribed to it. I don't think this will inconvenience any legitimate
users of this list, but please let me know if I am wrong.

Victor Mote

[FOray-developer] =?iso-2022-jp?b?GyRCJCIkSiQ/JE4lUSU9JTMbKEI=?= =?iso-2022-jp?b?GyRCJXMkLDx9Rn4lRCE8JWskSyRKJGokXiQ5ISMbKEI=?=

[<ta...@j-...>]

━独占広告━━━━━━━━━━━━━━━━━━━━━━━━━━
 
 
 　　　　  Home Office World Office inc.
     　　　　　≪第１4期募集要項≫
 　　　 　http://www.j-netshop.com/business.htm
 
 
 　　　　　◆家のパソコンを利用して、収入を得たい方
 　
 　　　　　◆空いた時間を利用して副業したい方
 　
 　　　　　◆自由な時間を利用しておこづかいを稼ぎたい主婦の方
 
 　
 　　　　　※すでにアメリカとヨーロッパで成功しているシステムを
 　　　　　　自宅のパソコンで、収入ツールとして利用してください。
 
 　　　　　　または、自宅で仕事をしたい方をご紹介下さい。
        　　　http://www.j-netshop.com/business.htm
 
 
 
 
 --[PR]------------------------------------------------------------------
  フリーメール 【Eqqu】(エキュ)のご案内です。　　↓　　↓　　↓
  無料でメールアドレスが持てて実に便利です。http://www.eqqu.com/?Harbar
  -----------------------------------------------------------------------
 
 ★━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━★
 このご案内は、提携マガジン一般広告購読希望者様とデジタル-Ｊ.net
 にご参加頂いているメンバー様に送信させて頂いております。
 
 発行元　　：【J-NET】
 　
 E-Mail    ： in...@di...　　　　　　　　　　　　　　　　　
 
 ---マガジン解除と免責事項-----------------------------------------
 
 ■メールマガジンの購読、解除について当メールマガジンは一括投稿サイ
   トへ投稿された方、無料投稿された方に配信させていただいております。
   投稿または登録した覚えのない方は、お手数ですが下記のURLよりお願い
   します。解除につきましては、２日から３日程お時間を頂くこともござ
   いますのでご了承ください。
 
 　　解除URL http://formlan.com/form2/aoyama3/
 
 ■免責事項とお願いお客様ご依頼のＰＲ本文中に含まれるＨＰ情報等は、
    確認の上掲載しておりますが、トラブルが発生した場合、当方では一切の
    責任は負いかねます。ＰＲ投稿本文やＨＰリンクの内容等についてのクレ
    ーム、損害等は当方では一切受け付けておりません。
 ★━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━★
 
 
 --[PR]------------------------------------------------------------------
 ★☆★＿＿＿＿＿＿＿＿＿＿┌─┬─┬─┬─┬─┬─┬─┬─┬─┐★☆★
 　　　話題の作るヨーグルト│ケ│フ│ィ│ア│ヨ│ー│グ│ル│ト│
 ★☆★￣￣￣￣￣￣￣￣￣￣└─┴─┴─┴─┴─┴─┴─┴─┴─┘★☆★
 トライアルキット好評発売中！カナダ農場直輸入ピュアメープルシロップ付！
  http://ad.freeml.com/cgi-bin/ad.cgi?id=djYud
 ------------------------------------------------------------------[PR]--
 ■GMO GROUP■ Global Media Online  www.gmo.jp

[FOray-developer] US Market

[Taranaki D. <mm...@te...>]

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.2912" name=3D"GENERATOR">
</HEAD>
<BODY>
<DIV><FONT color=3D#800000><STRONG>INVESTMENT ALERT FOR OUR=20
READERS</STRONG></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV align=3Dcenter><STRONG>Interest for VGYI has been picking over the =
preceding=20
months and interest is expected to continue with a massive PR campaign =
in the=20
days to follow.&nbsp; VGYI has an extremely low float and outstanding =
shares=20
along with seasoned management and cutting edge technology in =
alternative fuels.=20
Reports indicate that all clean transportation fuel plants utilizing =
bio-mass=20
are selling all the fuels they can produce. VGYI looks like a winner to=20
us!</STRONG></DIV>
<DIV align=3Dcenter>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><STRONG><FONT color=3D#000080>Outstanding Shares:&nbsp; 23,749,972 =
per recent=20
8K<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
Float:&nbsp; 1,300,000 approx. </FONT></STRONG></DIV>
<DIV>&nbsp;</DIV>
<DIV><BR><STRONG>Recent News:</STRONG></DIV>
<DIV><STRONG></STRONG>&nbsp;</DIV>
<DIV><STRONG></STRONG>&nbsp;</DIV>
<DIV><STRONG></STRONG>&nbsp;</DIV>
<DIV align=3Dcenter><STRONG>Vision Energy Group, Inc. Prepares to =
Purchase=20
Biodiesel Production Unit</STRONG></DIV>
<DIV align=3Dcenter>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><BR><STRONG><FONT color=3D#000080>Company Name: Vision Energy Group =
Inc.=20
<BR></FONT>Lookup: VGYI.PK</STRONG><BR>Current Price: $.45 (50% gains =
expected=20
this week!!)<BR><FONT color=3D#008080><STRONG>Expected: HEAVY PRICE =
INCREASES TO=20
CONTINUE</STRONG></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><BR><FONT color=3D#000080>About Vision Energy Corp.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>Vision Energy Corp. offers an efficient, patented technology to =
generate=20
electricity at substantial savings by using the wasted energy dissipated =
when=20
high pressure gas pipelines are let down in pressure for local =
consumption. Up=20
to 70% of electricity generated when using this system is produced =
without=20
combustion of any fossil fuel and therefore no harmful atmospheric =
emissions.=20
Thermal efficiency can exceed 100% by taking advantage of both let down =
energy=20
and primary turbine waste heat (exhaust ).</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><STRONG>WATCH THIS STOCK GO HIGHER AND HIGHER</STRONG></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><BR><FONT size=3D1>Any of the above statements with respect to the =
future=20
predications or goals and events may be seen as only Forward Looking and =
nothing=20
else. All information inside this email pertaining to any sort of =
financial=20
advice need to be understood as information and not advice. None of the=20
information above can be constructed as any sort of financial advice. =
This is a=20
paid advertisement.</FONT></DIV></BODY></HTML>

[FOray-developer] Greetings April

[April M. <bes...@aa...>]

LOOK AT OUR RECENT NEWS! ASK YOUR BROKER NOW!
INVESTORS ALERT! Friday, Dec 8, DTGP

Company: Doll Technology Group (OTCBB:DTGP)
Symbol: DTGP
Current Price: $0.016 (Trading at a Discount!)
3-day Target: $0.07 

Friday, Dec 8, will bring big trading for DTGP, which will mean it goes up!
Ladies and gentlemen, this one is incredible. 
This company is currently preparing to introduce their stock DTGP to brokers
across the country.
Look at their recent news and see what they are doing, and have been doing
in the past few Month.

About DTGP:
Doll Technology Group (OTCBB:DTGP)  diversified company formed to develop and commercialize products and technologies that address Aircraft Safety, Water Conservation, Fire Protection, Rust and Corrosion, and Construction, among others.

CALL YOUR BROKER NOW!