PDF to JavaFXML conversion – Creating a JavaFXML application with NetBeans: Adding images

In this blog I am going to show how you can include images to the scene graph, as a normal image or as a button.

First of all we have to import the image library into the Sample.fxml file. This can be doing using this code.

<?import javafx.scene.image.*?>

Now we can begin. Before we can even give the location of the image we want to display on the scene. We have to pad it in a couple of tags first, these are <ImageView> <image> and finally the <Image> tags. Notice the difference between the two image tags the <Image> tag carries the url (image location) while the <image> tag nests the the <Image> tag. Like this.

<ImageView layoutX="160" layoutY="100">
    <image>
      <Image url="@logo.gif"/>
    </image>
</ImageView>

Just like the hash tag (#) is used to differentiate between String and Methods, the at (@) symbol is also used to differentiate between String and relative Directories. So in this example the image logo will loaded from  the same folder as the Sample.fxml file. However, if the image was to be in a img directory the url would be @img/logo.gif. Before clicking on the run button, lets give the image a location on the scene to be on. Add the following to the <ImageView> tag layoutX=”160″ layoutY=”100″ like this.

<ImageView layoutX="160" layoutY="100">

This is what it looks like (does the logo look familiar, ;) ).

To add an image to a button firstly you have to create a button and embed the <graphic> tag before finally adding the image mark up just like we did when adding the image.

<Button>
   <graphic>
      <ImageView>
         <image>
            <Image url="@smback.gif"/>
         </image>
      </ImageView>
   </graphic>
</Button>

To give the button a location on the page we do the same thing we did with the <ImageView> tag, add layoutX=”250″ layoutY=”120″ to the button. Just for completeness I will add the textColor method to this button as well which means instead of clicking on the big buttons for the text to change color and size, the new button would be able to achieve the same feat.

<Button layoutX=”250″ layoutY=”120″ onAction=”#textColor”>

This is what you should have displayed which triggers the same method as the previous button.

To add the finishing touches to the button, I am now going to add a tool tip to the button giving users hints on the use of the button. The <tooltip> tag is on the same level as the <graphic> tag so inside the <Button> tag. Within the <tooltip> tag we need to include a <Tooltip> tag which has the message to be displayed. For example.

<tooltip>
    <Tooltip text="Change text color" />
</tooltip>

This is what it should look like.

What do you guys think? What else do you want to see added to the app?

Related Posts:

Posted in Java, javafx, PDF | Tagged , , | Leave a comment

SVG – is it now worth considering?

SVG has always been a technology for tomorrow (and looked like it would always stay that way). It is a really nice technology but it lacked the killer feature which meant people would adopt it today because it served an urgent problem. It found some interesting ‘niche’ uses (for example for icons in Linux desktop) but it had the classic problem of how you get out of the trap that there are few tools (especially viewers) and no killer usage, so few people use it so there are few tools.

Recently, however, I have become convinced that SVG has finally become a useful technology for today. The key change is the support of SVG in web browsers where it offers some useful advantages. In particular, you can use SVG inside HTML5 and it offers a number of advantages to canvas for display. As we are looking to provide the best possible PDF to HTML5 conversion, this is obviously of interest to us! We have already built PDF to HTML5, PDF to javafx, PDF to print, PDF to text, PDF to screen, PDF to image around our PDF parser so we have a fairly good idea how to do PDF to SVG.

So I think you can expect a whole series of PDF to SVG articles on our blog and if you come to our Javaone stand at San Francisco in October, I will be able to show you some interesting stuff. Should you be looking at SVG today?

Related Posts:

Posted in svg | Tagged , , | Leave a comment

PDF to HTML5 conversion – Invisible text appears in HTML5

I have been looking at some interesting PDF files recently… In one of them we had a PDF file where we could see extra text on the HTML5 pages – in the PDF we had a blank white box while the HTNL5 page had a white box with text on it. Very odd :-(

 

So we drilled down into the PDF to see what was going on.

It actually turns out that the text is selectable on the PDF and you can extract it with a copy paste. It is just not visible, because the white box is drawn ontop of the text, hiding it.

When we generate an HTML5 version of the page we usually use TWO separate layers – the canvas layer and the text divs. These layers do not intermesh as closely so the text layer is effectively drawn ontop of the canvas. This is why we can see the text. There are several solutions to this problem.

Firstly, we could draw all the text on the canvas layer. We have actually added a method to rasterize the text where the page looks as it does on the PDF.

There are also 2 future fixes we could also add. We could write all the text out to SVG or we could scan the page twice – the first time to find all the shapes so we could then decide if the text was hidden. The downside of this would be it would slow do the processing speed. They are both possible commercial enhancements we could add for clients in the future.

Do you have any interesting PDF to HTML5 conversion issues you would like us to investigate?

Related Posts:

Posted in html | Tagged , | Comments Off

PDF to HTML5 conversion – setting your own text widths

When we convert PDF to HTML5 content, we allow several options to embed or replace fonts. Sometimes you want something more sophisticated. How, for example could you use different font widths if you want to replace the font?

What we do not want is for the user to have to customise every new version of the code we release. So we can make use of Interfaces to make this easy to do. The actual PDF to HTML5 conversion is done by a class HTMLDisplay setup in the example ExtractPagesAsHTML. This is actually an implementation of the interface DynamicVectorRenderer so you can change


DynamicVectorRenderer HTMLoutput=new HTMLDisplay(page, midPoint, cropBox ,false, 100, new ObjectStore());


DynamicVectorRenderer HTMLoutput=new MyCustomHTMLDisplay(page, midPoint, cropBox ,false, 100, new ObjectStore());

MyCustomHTMLDisplay is your class which extends HTMLDisplay.

The reason to do this is to add a small change into your new class. The PDF to HTML5 conversion calls this routine for each glyf. We set the width to a non-possible value (-100) and override it.


public void drawEmbeddedText(float[][] Trm, int fontSize, PdfGlyph embeddedGlyph,
Object javaGlyph, int type, GraphicsState gs,
AffineTransform at, String glyf, PdfFont currentFontData, float glyfWidth){

//if -100 we get value – allows user to override
if(glyfWidth==-100){
glyfWidth=currentFontData.getWidth(-1);
}

 

So we just need to override this in our new class and call the super method!


public void drawEmbeddedText(float[][] Trm, int fontSize, PdfGlyph embeddedGlyph,
Object javaGlyph, int type, GraphicsState gs,
AffineTransform at, String glyf, PdfFont currentFontData, float glyfWidth){

//adjust the width (which will usually be 0-1000 here) and anything else

super.drawEmbeddedText(Trm, fontSize, embeddedGlyph, javaGlyph, type, gs, at, glyf, currentFontData, glyfWidth)

That gives us a robust solution with minimal changes between releases and as little code duplication as possible. What do you think?

Related Posts:

Posted in html | Tagged , , | Comments Off

Interesting PDF bugs – Missing image data

I have been looking at a customer file which illustrates one of my least favourite features of the PDF file spec – the need to constantly check everything. Take for example the case of image data.

In the customer PDF file I have an image. To make the maths simple, let us say it was a 1 bit image 80 pixels wide and 10 pixels high. As each byte contains 8 pixels that means we need 10 bytes to hold the pixel data so a total of 100 bytes.

However, some tools ignore any blocks of white at the end. In this case, the bottom of the image is white (ie blank) so I am given only 60 bytes of data. I am expected to assume that the last 40 bytes of data are white and fill in. As Java is meticulous at expecting the data array for an image to contain data for all the pixels (larger is allowed and it will then ignore), it will throw an error if I try to turn this into a BufferedImage. I have to check the size of all image data and ‘correct’. Here is some code if you ever need to do this yourself.

if(decodeColorData.getID()== ColorSpaces.DeviceGray){
   if(d==1){
            int requiredSize=((w+7)>>3)*h;
            int oldSize=data.length;
            if(oldSize<requiredSize){
                byte[] oldData=data;
                data=new byte[requiredSize];
                System.arraycopy(oldData,0,data,0,oldSize);

                //and fill rest with 255 for white
                for(int aa=oldSize;aa<requiredSize;aa++)
                    data[aa]=(byte)255;
            }

        }else if(d==8){
            int requiredSize=w*h;
            int oldSize=data.length;
            if(oldSize<requiredSize){
                byte[] oldData=data;
                data=new byte[requiredSize];
                System.arraycopy(oldData,0,data,0,oldSize);
            }
        }
    }
}

So when you extract the data from a PDF file for your own uses, you will often need to ‘fix’ it and fill-in the missing bits (literally in this case).

Another file fixed, but I do sometimes miss a spec which actually enforces the spec. Do you think this would be a good idea?

 

Related Posts:

Posted in Image | Tagged , , , | 2 Comments