Java PDF Blog

PDF solutions for big and small customers

Java and PDF development - our personal experiences and discoveries

Download JPedal

Download JPedal PDF viewers

PDF to Image service

Try our PDF to image conversion service now.

Java PDF Ebook Solution

Try our Ebook solution now.

Subscribe

Your email:

Java PDF blog

Current Articles | RSS Feed RSS Feed

Software Development: Are we listening carefully?

Posted by Sam Howard on Tue, May 25, 2010 @ 01:53 AM
Submit to Digg digg it |  Add to delicious  delicious |  Submit to StumbleUpon StumbleUpon | Submit to Reddit reddit 

The quality of documentation and tools in an area of software development has an incredible impact on us developers. They both influence how fast we can work, the quality of the software we write, and even how we feel about our work.

I've recently been working on adding some support for hinting into our TrueType font renderer. I was delighted to find a number of excellent tools for working with TrueType fonts, such as Microsoft's font tools and FontForge, but unfortunately found the TrueType documentation rather lacking.

Instructed font hinting like that used in TrueType fonts is a complicated subject. Each glyph contains a small (ish!) program written in TrueType byte code, which is run in order to manipulate the points. This manipulation was initially designed primarily for grid fitting, a process which improved the appearance of text on screen before anti-aliasing became a feasible option, but is now also used extensively in foreign language fonts to move and change the shape of components of a compound glyph.

 

Japanese characters before and after their glyph programs have been run
Chinese characters before and after their glyph programs are run.


As can be expected with such a complex field, mistakes and ambiguities have crept into the documentation, and while generally very good, even the tools have some flaws.

TrueType was initially developed by Apple in response to Adobe's rather restrictively licensed Type 1 font technology, but was later licensed by Microsoft, eventually making it the de-facto standard on desktop computers. As a result, there are two primary sources of documentation – Apple and Microsoft. While they supposedly define exactly the same system, there are occasional direct contradictions in what they say! In fact, in Apple's guide the definition and example given for one of the most important byte codes is completely wrong.

This wouldn't be surprising in a new document – as I said, it's a complex topic – but these guides were written in the mid nineties! I can't be the first to have found these mistakes, but since in both cases there is no obvious way of contacting the authors, they've stayed incorrect for almost 15 years.

This, to me, highlights the need for a clear and direct line of communication between those writing specifications and those who use them – something we've been trying hard to achieve. Anything unclear? Let us know! We're here to help.

11 Comments Click here to read/write comments

Search in continuous mode and future plans

Posted by kieran france on Thu, Feb 18, 2010 @ 04:59 AM
Submit to Digg digg it |  Add to delicious  delicious |  Submit to StumbleUpon StumbleUpon | Submit to Reddit reddit 
Tags: , , ,
For some time the Jpedal library has had the ability to search exclusively in single page mode. For our release of Jpedal 4.0 we have begun to expand this functionality to the other view modes. As a start we have added the search functionality to the continuous single page view mode with plans to expand this into the other view modes.

To allow for this new functionality we have needed to make alterations to a few of our exsisting public methods in order to allow for highlights to be assigned to or retrieved from a particular page.


On top of this the highlights are no longer stored in a Rectangle array. The highlgihts are stored in a Hashmap using the page number as the key and a Vector_Rectangle (org.jpedal.utils.repositories.Vector_Rectangle) as the associated value.


We have also moved the page text areas and text orientation into hash maps. In order to store this information it must be retrieved from PdfStreamDecoder after decodePageContent (PdfObject pdfObject, int minX, int minY, GraphicsState newGS, byte[] pageStream) is called as each call to this method will rewrite the localy stored data for the previous page.

The follow methods have changed in version 4.0 to allow for highlights of multiple pages being stored.

Commands.ExecuteCommands(Commands.HIGHLIGHT, new Rectangle[]{})
has become
Commands.ExecuteCommands(Commands.HIGHLIGHT, new Object[]{Rectangle[] areas, int page})

GethighlightAreas()
has become
GethighlightAreas(int page)

setFoundParagraph(int x, int y)
has become
setFoundParagraph(int x, int y, int page)

addHighlights(rectangle[], boolean)
has become
addHighlights(rectangle[], boolean, int page)

RemoveFoundTextArea(Rectangle)
has become
RemoveFoundTextArea(Rectangle, int page)

RemoveFoundTextAreas(Rectangle[])
has become
RemoveFoundTextAreas(Rectangle[], int page)

 

As you will notice the above methods have had a new integer added as an input called page. This value is the page number to which you wish to direct the method.


As well as the above methods the following method has also changed.

Display.initRenderer(Rectangle[] areas, Graphics2D g2,Border myBorder,int indent)
has become
Display.initRenderer(Map areas, Graphics2D g2,Border myBorder,int indent)

The above method would originaly recieve the rectangle array we used to use for highlighting. We have updated the method to accept a map as this is how the highlights are now stored.

 

Earlier in this article was mentioned that PdfStreamDecoder holds a local copy of the text areas and orientation when a pages content is decoded. In order to retrieve this data we have added the follow two methods.

Vector_Rectangle getTextAreas()

Vector_Int getTextDirections()

In the releases to follow we will be moving more functionality into the continuous single page view mode, then to the other view modes, such as highlighting with the mouse, extraction and the right click menu.

0 Comments Click here to read/write comments

JPedalFX - a JavaFX PDF Viewer

Posted by sam howard on Fri, Dec 11, 2009 @ 01:44 PM
Submit to Digg digg it |  Add to delicious  delicious |  Submit to StumbleUpon StumbleUpon | Submit to Reddit reddit 

During a recent trip to Sun Microsystems' customer briefing centre in London I sat through an enjoyable overview of JavaFX and its short-term future. While I had heard of it before, it was interesting to see how easily exciting interfaces could be put together. I couldn't help but think how several things I have implemented in Java could have been implemented much more quickly in JavaFX, so I decided to spend a few hours trying it out.

There's lots of great example code at javafx.com, which provides a good starting point. As can be expected, it is very similar to Java, and any Java developer should be able to start writing code almost straight away. The obvious choice was to write a simple PDF viewer, which I then did using spare moments over the past week or so. The result is JPedalFX - an attempt at a clean and simple viewer.

 

 

My only complaint with JavaFX is the lack of ability to compile to a standard jar file which will run on the JVM. While you can do so by including the JavaFX jars in your product, it is apparently not allowed under JavaFX's licensing. In any case, deployment via Webstart is the preferred option, which (hopefully) suits JPedalFX well.

Over all, I am impressed at how quickly you can learn and develop in JavaFX, and the quality of the resultant applications. JavaFX is a much needed step towards putting UI design in the hands of designers rather than programmers, but it also provides a framework in which programmers can more easily create exciting interfaces.

Give JPedalFX a go, and see what you think. I'd love to hear your thoughts.

1 Comments Click here to read/write comments

All Posts