DEV Community: IDRSolutions

How to debug PDF files

IDRSolutions — Fri, 21 Aug 2026 13:09:55 +0000

The first JPedal release of 2023 has just been published and with it, some exciting new features have been added to our Java PDF debugger! With a PDF debugger, you can inspect and debug PDF files easily. Read about our new release here to find out more.

Viewing Images in the PDF debugger

You can now view images in JPedal’s own PDF debugger.

The Xref Viewer and the Object Tree Viewer both allow you to view the image content of XObjects. This can be done by selecting an XObject and pressing ‘Show Image’.

The Command Window allows you to view the image content of ID and DO commands. This can be done by right-clicking on the command and pressing ‘View Image’.

Read more about viewing images in the inspector here.

Debug Breakpoints

The Limit Decode Slider in the PDF debugger now has breakpoints.

You can select a command to toggle a breakpoint and pressing the resume button will decode the page up until the next breakpoint.

Xref Viewer Improvements

The Xref Viewer has been updated and now supports cross-reference streams as well as Xref tables.

Learn more

You can read more about JPedal’s PDF inspector on our website.

PDF Performance and UX Issues in Web Publishing (Why PDFs Slow Down Websites)

IDRSolutions — Wed, 19 Aug 2026 08:50:56 +0000

Why PDFs Cause Performance and UX Issues in Web Publishing

Embedding PDFs in websites is a common approach for digital publishing platforms, but it often introduces performance and user experience issues that are difficult to control.

If you manage a publishing platform, content hub, or document-heavy application, you have likely seen slow load times, poor mobile usability, and limited flexibility when working with PDFs in the browser.

Understanding why PDFs struggle in web environments is key to improving both content performance and user engagement.

Why Do PDFs Load Slowly on Websites?

PDFs load slowly on websites because they are large, fixed layout files that require full document rendering in the browser. Unlike HTML, which loads progressively, PDFs often need to be processed in full before users can interact with them. This increases load times, especially for image-heavy or long documents, and impacts performance across devices.

Why PDFs Slow Down Websites (PDF Performance Issues)

PDFs are typically large, high-fidelity files designed to preserve layout and visual accuracy. While this is useful for print and distribution, it creates performance challenges when delivered through a browser.

Rendering a PDF requires significant browser resources. Instead of loading lightweight, structured web content, the browser must process an entire document, often including high-resolution images and complex formatting.

For publishing platforms, this results in slower page load times, delayed interaction, and inconsistent rendering across devices. As content libraries scale, these performance issues compound, impacting overall site speed and increasing bounce rates.

The impact is even more pronounced on mobile, where bandwidth and processing power are limited, and users expect fast, responsive experiences.

PDF User Experience Problems (Mobile and Responsive Issues)

PDFs are not designed to be responsive. On mobile devices, users often need to zoom, pan, and manually navigate documents just to read basic content.

This creates friction compared to native web pages, where content automatically adapts to screen size and supports intuitive scrolling and interaction.

For publishers, this directly affects engagement metrics. When users struggle to consume content, they are more likely to drop off, reducing time on page and overall retention.

Why PDFs Don’t Work Well on Websites

At a fundamental level, PDFs were built for print, not for the web. They are fixed-layout documents, whereas modern web experiences rely on flexible, responsive, and interactive content.

When PDFs are embedded into websites, they rely on browser-based rendering engines that limit performance, control, and consistency. This makes it difficult for publishing teams to optimise content delivery, personalise experiences, or integrate seamlessly with web analytics and workflows.

As a result, PDFs often become a constraint rather than an enabler in digital publishing environments.

Better Alternatives to PDFs for Web Publishing

To address these challenges, many publishing platforms are moving towards web-native formats such as HTML5 and SVG.

By converting PDFs into HTML5 content, publishers can deliver faster load times, responsive layouts, and a more seamless reading experience across devices.

This approach also provides greater control over content structure, styling, and interaction, making it easier to optimise performance, improve accessibility, and integrate with existing web systems.

For publishing teams managing large volumes of content, this shift enables better scalability and a more consistent user experience.

How to Fix PDF Performance and UX Issues in Web Publishing

PDFs remain useful for document distribution, but they introduce clear limitations when used within web publishing platforms.

If performance, responsiveness, and user engagement are priorities, relying on embedded PDFs can hold your platform back.

Converting PDFs into web-native formats offers a more scalable and user-friendly solution. Tools like BuildVu enable publishing teams to transform PDFs into fast, responsive HTML5 content that works seamlessly in the browser.

By making this shift, publishing platforms can reduce friction, improve load times, and create a better experience for their users.

Explore more ways to improve digital publishing performance, user experience, and content delivery at scale. Trial BuildVu now to convert your PDFs into fast, web-native HTML5 content.

Comparing TIFF Compression Algorithms

IDRSolutions — Fri, 14 Aug 2026 12:47:38 +0000

In this post, we will be exploring the different TIFF compression techniques you can use. We will investigate their effect on different metrics such as file size, quality of output, and speed. We will be using our image library JDeli to compress a TIFF file (sample image). JDeli is the best pure Java image library for performance and efficiency.

For the baseline of our comparisons, we will use the following uncompressed image. It has a file size of 39.3MB. It takes just under 5 seconds to encode.

JPEG

First introduced in the 90s, JPEG has remained a popular compression format for images due to its decent tradeoff between quality and file size. JPEG is lossy meaning you cannot recover the original pixel data from the compressed image.

Straight off the bat, we see a dramatic reduction in file size: 1.2MB! Even with this tiny file size, the quality of the image is only slightly worse than the original.

Viewing at its default resolution, it is hard to tell the difference, however upon zooming in you will notice a less sharp image with slightly more noise and artefacts. Using JPEG compression, the encoding takes around 5 seconds, it is almost as quick as the original.

LZW

Lempel–Ziv–Welch (named after its creators) was introduced in 1984, and is used today by Unix’s compress program. It is also the compression algorithm used in GIF images.

Using LZW compression, we observe a file size of 18MB. Since LZW is lossless, there is no reduction in the quality of the image. Like JPEG, encoding with LZW takes around 5 seconds.

An interesting quirk about LZW is that is has the potential to make file sizes bigger. An image with lots of noise will not see a reduced file size if compressed with LZW.

DEFLATE

DEFLATE was also designed in the 90s and is popular in PNG images and also the ZIP archive format.

Using DEFLATE, the file size is reduced. Like LZW, DEFLATE is lossless, so the quality of the compressed image remains the same as the original. The downside of DEFLATE however, is that it takes much longer to encode.

Conclusion

In conclusion, there is no best tiff compression algorithm that solves all problems. JPEG is best if you want a tiny file size with a small reduction in quality however LZW and DEFLATE are necessary if you want to preserve the original image. LZW encodes slightly larger than DEFLATE but is much faster so the answer will depend on your use case.

As experienced Java developers, we help you work with images in Java and bring over a decade of hands-on experience with many image file formats.

How to find PDF page size in Java (Tutorial)

IDRSolutions — Wed, 12 Aug 2026 10:00:48 +0000

PDF files are not directly supported by Java. This tutorial shows you how to extract PDF page size (height and width) from a PDF file in simple steps using the JPedal Java PDF library. JPedal is the best Java PDF library for developers. The page size can be defined in Centimetres, Inches and pixels.

Why use a third-party library to handle PDF files?

PDF files are a very complex binary/text hybrid data structure which is a subset of the even more complicated Postscript format. In this example, we will use our JPedal Java PDF library to make this task simple.

How to find PDF page size in Java

Add JPedal to your class or module path. (download the trial jar).
Create a File handle, InputStream, or URL pointing to the PDF file
Include a password if file password protected
Open the PDF file
Extract the data for each page
Close the PDF file

and the Java code to find PDF Page size…

PdfUtilities extract=new PdfUtilities(path);
extract.setPassword("password"); //if needed
int pageCount = extract.getPageCount();
for (int page = 1; page <= pageCount; page++) {
    if (extract.openPDFFile()) {
        float[] pageDimensions = extract.getPageDimensions(pageNum,
        PageUnits.Inches, PageSizeType.CropBox);
    }
}
extract.closePDFfile();

Further useful links

Blog post explaining how MediaBox and CropBox define a PDF page size
Javadoc link to PageSizeType class which defines whether to use MediaBox or CropBox (if in doubt use CropBox)
Javadoc link to PageUnits class which defines sizes
Javadoc link to PageUtilities class which documents this Utility class

Measure content performance with Analytics – Why convert PDF magazines to HTML5?

IDRSolutions — Fri, 07 Aug 2026 13:22:43 +0000

One of the things that all good content producers rely heavily on is analytics. Analytics give you the opportunity to see what is doing well (the stuff you need to do more of), and what isn’t doing well (the stuff you need to do less of).

Not only do they let you know about the performance of your content, but they can also give you information about the people consuming your content. For example, there is a 7.28% chance that you are reading this from Germany (shout out to our German readers!). This allows you to tailor your content to your demographics and to bring in better quality traffic.

For those of you advertising to your readers, you can also increase your ad revenue by targeting your readers with adverts that you know are most relevant to them. For example there are companies that pay Facebook good money to display their dating website advert to the users who have recently set their relationship status to Single.

Unfortunately this is something that PDF is completely lacking, but by converting to HTML5 you can enable this functionality, and start measuring your content and demographics!

You can use our online converter to test the PDF conversion to HTML. Try out some sample copies and start tracking right away!

This article is part of a series where we talk about the advantages of publishing your PDF magazines online as HTML5. Click here to see more advantages.

Java CMYK to RGB Conversion – Speed Comparison

IDRSolutions — Thu, 06 Aug 2026 14:03:12 +0000

Introduction

Some optimisations are best left to Java. For example a System.arraycopy is the fastest way to create a new version because it is optimised in hardware inside Java. So in general, any function which might have hardware optimisation is best left to the JVM.

So what about image data conversion? Is it better to delegate it to Java or Do It Yourself? I have been looking at a file which was slow to decode. The bottleneck turned out to be the CMYK to RGB conversion so I decided to have a look…

Version 1: Using ColorConvertOp

My original code used a ColorConvertOp to do the image conversion on the raw CMYK data and then create an RGB image with the converted data. Here is the code.

int[] bands = { 0, 1, 2, 3 };
/**turn it into a BufferedImage so we can filter*/DataBuffer db = new DataBufferByte(data, data.length);
/**create RGB colorspace and model*/ColorSpace rgbCS=GenericColorSpace.getColorSpaceInstance();
/**define the conversion. hints can be replaced with null*/ColorConvertOp CSToRGB = new ColorConvertOp(
   DeviceCMYKColorSpace.getColorSpaceInstance(), rgbCS,
   ColorSpaces.hints);
/**create RGB colorspace and model*/ComponentColorModel rgbModel = new ComponentColorModel(
   rgbCS, new int[] { 8, 8, 8 }, false, false, ColorModel.OPAQUE,
   DataBuffer.TYPE_BYTE);
image =new BufferedImage(width,height,BufferedImage.TYPE_INT_RGB);
WritableRaster rgbRaster=rgbModel.
   createCompatibleWritableRaster(width, height);
CSToRGB.filter(Raster.createInterleavedRaster(db, width,
   height, width*4, 4, bands, null), rgbRaster);
image.setData(rgbRaster);

On the sample page it takes 73 seconds on my fast Mac.

Version 2: Manual Pixel Conversion

Version 2 does the pixel conversion manually and then builds the image from that. A major advantage of this is that I can add optimisations. In this case I cache the last value so I only need to do the conversion if the value changes – on an empty page of 10,000 white pixels, I will get a massive boost as I only need to convert the value once and reuse it.

ColorSpace CMYK=DeviceCMYKColorSpace.getColorSpaceInstance();
BufferedImage image = null;
byte[] new_data = new byte[w * h * 3];
int pixelCount = w * h*4;
float lastC=-1,lastM=-1,lastY=-1,lastK=-1;
float C, M, Y, K;
float[] rgb=new float[3];
/**
* loop through each pixel changing CMYK values to RGB
*/int pixelReached = 0;
for (int i = 0; i < pixelCount; i = i + 4) {
C = (buffer[i]&0xff)/255f;
M = (buffer[i + 1]&0xff)/255f;
Y = (buffer[i + 2]&0xff)/255f;
K = (buffer[i + 3]&0xff)/255f;
if(lastC==C && lastM==M && lastY==Y && lastK==K){
//use existing values if not changed
}else{//work out new
rgb=CMYK.toRGB(new float[]{C,M,Y,K});
//cache values
lastC=C;
lastM=M;
lastY=Y;
lastK=K;
}
new_data[pixelReached++]=(byte)(rgb[0]*255);
new_data[pixelReached++]=(byte)(rgb[1]*255);
new_data[pixelReached++]=(byte) (rgb[2]*255);
}
/**
* turn data into RGB image
*/image =new BufferedImage(w,h,BufferedImage.TYPE_INT_RGB);
Raster raster = createInterleavedRaster(new_data, w, h);
image.setData(raster);

Performance Comparison

The method is longer, but what is the speed difference? On my Mac this takes an astonishing 11 seconds! My next task is to see whether it is the same on other platforms…

I’ve kept the old code (in the hope Oracle one day optimises the filter function), but for the moment you can guess which version I am using…

Have you found any similar cases where a DIY approach is much faster?

As experienced Java developers, we help you work with images in Java and bring over a decade of hands-on experience with many image file formats.

How to search a PDF file in Java (Tutorial)

IDRSolutions — Wed, 05 Aug 2026 13:38:29 +0000

This tutorial shows you how to find words in a PDF file in simple steps using the JPedal Java PDF library. JPedal is the best Java PDF library for developers. It includes a PDF search engine that provides an easy-to-use Java PDF API to find words and phrases in a PDF document.

How to search PDF file in Java

Download JPedal trial jar.
Create a File handle, InputStream or URL pointing to the PDF file
Include a password if file password protected
Open the PDF file
Scan the pages
Close the PDF file

and the Java code to search a PDF…

File file = new File("/path/to/document.pdf"));
FindTextInRectangle extract=new FindTextInRectangle(String.valueOf(file));
//extract.setPassword("password");
if (extract.openPDFFile()) {
    int pageCount = extract.getPageCount();
    for (int page = 1; page <= pageCount; page++) {
        float[] coords = extract.findTextOnPage(page, "textToFind",
                SearchType.MUTLI_LINE_RESULTS ) ;
    }
}
extract.closePDFfile();

Why can’t I just search the PDF file directly?

You cannot simply search inside a PDF file because the text data is stored in a special binary format.

iOS and HTML5: Gotcha with Absolute Positioning

IDRSolutions — Wed, 29 Jul 2026 08:52:21 +0000

Introduction

One of the aims of BuildVu and all of its various view modes (all 9 of them) was to make viewing of PDF files easy and platform-independent, where the user only needs a relatively modern web browser to view them.

And as we designed the output to be used by the browser, we also allow you to select and search the text using your browser’s default tools, and this free functionality normally works great in all web browsers, across all platforms, even Android devices, as you can see in the images in this post.

Issue on iOS Browsers

However, this sadly isn’t true within Apple’s current version of Safari on iOS and Chrome on iOS. Currently, both don’t quite support all the latest CSS to as great a degree as other mobile devices, and as a result of its bizarre Selection engine, it’s very difficult and often impossible to select text on pages containing complicated CSS (explained below).

We recently had a customer query us about why they couldn’t select the text of our output on their iPad, which struck us as an odd question; the default mode for our output has had selectable text for as long as I can recall so my initial thought was that it may have just been a user unfamiliar with how to select text on an iPad. However, we still checked to be sure and were surprised to find that the text wasn’t selectable.

This was puzzling because, as I mentioned before, the text has always been selectable, it is, after all, just text within a div tag in the HTML, and we were sure it worked previously.

Investigating the Problem

After going over our current output, I found some older output that worked and had a look at the differences to the current version.

Visually they looked almost identical, with a few improvements in regard to character spacing in our current version and a different background colour.

Structurally, the newer version differs quite a lot from the older version. In our older versions, we placed the text within div tags under our parent jpedal tag with styling like so:

<body style="background-color: rgb(55,55,65);">
<div id="jpedal" style="position:relative; width: 984px; margin: 0 auto;">
<!– Shared CSS values –>
<style type="text/css" >
.t {
position:absolute;
white-space:nowrap;
overflow:visible;
z-index:1;
}
.tr {
-webkit-transform-origin: left top;
-ms-transform-origin: left top;
-moz-transform-origin: left top;
-o-transform-origin: left top;
}
</style>
<!– Inline CSS values –>
<style type="text/css" >
#t1_1 {
left:90px;
top:60px;
FONT-SIZE: 60px;
FONT-FAMILY: CataneoBT-Regular1;
color:rgb(0,85,149);
}
#t2_1 {
-webkit-transform:matrix(0.97,0,-0.2,0.97,114, 181);
-ms-transform:matrix(0.97,0,-0.2,0.97,114, 181);
-moz-transform:matrix(0.97,0,-0.2,0.97,114, 181);
-o-transform:matrix(0.97,0,-0.2,0.97,114, 181);
FONT-SIZE: 21px;
FONT-FAMILY: IGNACK-RaleighBT-Roman1;
color:rgb(35,32,32);
}
#t3_1 {
-webkit-transform:matrix(0.97,0,-0.2,0.97,350, 212);
-ms-transform:matrix(0.97,0,-0.2,0.97,350, 212);
-moz-transform:matrix(0.97,0,-0.2,0.97,350, 212);
-o-transform:matrix(0.97,0,-0.2,0.97,350, 212);
FONT-SIZE: 13px;
FONT-FAMILY: IGNACK-RaleighBT-Roman1;
color:rgb(35,32,32);
}
</style>
<!– Any embedded fonts defined here –>
<style type="text/css" >
@font-face {
font-family: CataneoBT-Regular1;
src: url("01/fonts/CataneoBT-Regular.woff");
}
@font-face {
font-family: IGNACK-RaleighBT-Roman1;
src: url("01/fonts/IGNACK-RaleighBT-Roman.woff");
}
</style>
<!– Text defined here and setup in CSS –>
<div id="t1_1″ class="t">Some things never change</div>
<div id="t2_1″ class="t tr">Never trust a dog to watch your food.</div>
<div id="t3_1″ class="t tr">â��</div>

We simply apply the correct styling and letter spacing to each element via its class and ID attributes.

Introduction of Parent Divs

To reduce the large amount of class=”t”, which is a CSS class in our older output that contained some CSS rules common to all of our text and other repeated values in the CSS for each div’s ID, we introduced several parent divs that reduce file size and make our CSS easier to understand.

Example of Current Output

Below you can see an example of the current output and it’s structure (Note: As with the previous example, this is just a snippet of the relevant parts of our output):

<body style="background-color:#919191;">
<div id="jpedal" style="position:relative; width: 984px; height: 1179px; overflow: hidden; margin: 0 auto; box-shadow: 0 2px 6px rgba(100, 100, 100, 0.5);">
<!– Begin shared CSS values –>
<!–[if lt IE 9]><style type="text/css">.text div div{zoom: 25%;}</style><![endif]–>
<style type="text/css" >
.text {
position: absolute;
-webkit-transform-origin: top left;
-moz-transform-origin: top left;
-o-transform-origin: top left;
-ms-transform-origin: top left;
-webkit-transform: scale(0.25);
-moz-transform: scale(0.25);
-o-transform: scale(0.25);
-ms-transform: scale(0.25);
z-index: 1;
}
.text div div {
position:absolute;
white-space:nowrap;
overflow:visible;
}
</style>
<!– End shared CSS values –>
<!– Begin inline CSS –>
<style type="text/css" >
#t1_1{left:360px;top:240px;}
#t2_1{-webkit-transform:matrix(0.97,0,-0.2,0.97,456, 724);-ms-transform:matrix(0.97,0,-0.2,0.97,456, 724);-moz-transform:matrix(0.97,0,-0.2,0.97,456, 724);-o-transform:matrix(0.97,0,-0.2,0.97,456, 724);}
#t3_1{-webkit-transform:matrix(0.97,0,-0.2,0.97,1400, 848);-ms-transform:matrix(0.97,0,-0.2,0.97,1400, 848);-moz-transform:matrix(0.97,0,-0.2,0.97,1400, 848);-o-transform:matrix(0.97,0,-0.2,0.97,1400, 848);}
#t4_1{left:1456px;top:848px;}
#t2_1,#t3_1 {
-webkit-transform-origin: left top;
-ms-transform-origin: left top;
-moz-transform-origin: left top;
-o-transform-origin: left top;
}
.s2_1{
FONT-SIZE: 84px;
FONT-FAMILY: IGNACK-RaleighBT-Roman1;
color: rgb(35,32,32);
}
.s1_1{
FONT-SIZE: 240px;
FONT-FAMILY: CataneoBT-Regular1;
color: rgb(0,85,149);
}
.s3_1{
FONT-SIZE: 52px;
FONT-FAMILY: IGNACK-RaleighBT-Roman1;
color: rgb(35,32,32);
}
</style>
<!– End inline CSS –>
<!– Begin embedded font definitions –>
<style type="text/css" >
@font-face {
font-family: CataneoBT-Regular1;
src: url("index/fonts/CataneoBT-Regular.woff");
}
@font-face {
font-family: IGNACK-RaleighBT-Roman1;
src: url("index/fonts/IGNACK-RaleighBT-Roman.woff");
}
</style>
<!– End embedded font definitions –>
<!– Begin text definitions (Positioned/styled in CSS) –>
<div class="text">
<div class="s1_1″>
<div id="t1_1″>Some things never change</div>
</div>
<div class="s2_1″>
<div id="t2_1″>Never trust a dog to watch your food.</div>
</div>
<div class="s3_1″>
<div id="t3_1″>â��</div>

This reduced our output length by a lot; not having to output the font-family per ID and the class=”t” per element adds up to a lot of saved characters in the output files, which consequently makes large converted files with a lot of similar text smaller.

However, nesting these absolutely positioned elements appears to be what the issue is in iOS. This probably isn’t intended behaviour and may well be a bug with iOS!

Workaround and Conclusion

One solution we’ve come up with for this is to change the output on the page when navigated to in iOS to something it can select the text of. Of course, this affects the performance of our output when looked at on iOS devices, which isn’t the best compromise.

My personal hope is that this issue is rectified within iOS itself so that other developers don’t have to encounter this oddity.

Have you had any difficulties with selecting text on iOS or other web browsers? We’d love to hear about them and how you solved them!

How to Convert CCITT data to TIFF image (Tutorial)

IDRSolutions — Mon, 27 Jul 2026 11:27:37 +0000

What is CCITT data?

CCITT is used to compress black and white image data. Using Huffman encoding, the data is squeezed into a much smaller compressed stream.

CCITT is also a compression format used in the TIFF file format. By adding some additional bytes to your raw CCITT data, and saving it in a file ending .tif, you can create a TIFF Image from raw CCITT data. My example is written in Java (but it should be easy to recode in any language). It will take the raw data and add the required bytes.

CCITT data in PDF files

CCITT is used as a compression format in PDF files for images in XObjects. You can manually extract the CCITT data and the Dictionary values (K, isBlack, etc) from PDF files if you want to reuse the images.

If you have extracted the CCITT data from a PDF, there may be some differences between the raw image and the image in the PDF – remember this is the raw image which may be inverted, coloured, clipped, etc.

How to convert CCITT to a TIFF

Get the CCITT parameters
Create a metadata header
Append the raw CCITT data

and the Java code to write TIFF…

/*
 * default values (these may be set in a PDF DecodeParms dictionary)
 */ 
boolean isBlack = false;  //flag to show if default is black/white
int k = 0;
int w = -1;
int h = -1;

/*
 * build the image
 */ 
ByteArrayOutputStream bos = new ByteArrayOutputStream();

/*
 * tiff header (id, version, offset)
 */ 
String[] headerValues = {"4d", "4d", "00", "2a", "00", "00", "00", "08"};
for (int i = 0; i < headerValues.length; i++)
    bos.write(Integer.parseInt(headerValues[i], 16));

int tagCount = 9; // appears to be minimum needed
// writeWord and writeTag are convenience methods
// add the values as bytes to the stream

/* IFD – Image File Directory */ 
writeWord(String.valueOf(tagCount), bos); // num of entries
writeTag("256", "04", "01", String.valueOf(w), bos); // width
writeTag("257", "04", "01", String.valueOf(h), bos); // length

// BitsPerSample 258 – B&W 1 bit image
writeTag("258", "03", "01", "00010000h", bos);

if (k == 0)
    writeTag("259", "03", "01", "00030000h", bos); // compression
else if (k > 0)
    writeTag("259", "03", "01", "00020000h", bos); // compression
else if (k < 0)
    writeTag("259", "03", "01", "00040000h", bos); // compression

//photometricInterpretation
if (!isBlack)
   writeTag("262", "03", "01", "00000000h", bos);
else
   writeTag("262", "03", "01", "00010000h", bos);

//stripOffsets -start of data after tables
writeTag("273", "04", "1", "122", bos);

//samplesPerPixel
writeTag("277", "03", "01", "00010000h", bos);
//rowsPerStrip – uses height
writeTag("278", "04", "01", String.valueOf(h), bos);
//stripByteCount – 1 strip so all data
writeTag("279", "04", "1", String.valueOf(data.length), bos);
// write next IOD offset  zero as no other table
writeDWord("0", bos);

/*
 * write the CCITT image data at the end
 */ 
try {
   bos.write(data);
   bos.close();
} catch (IOException e) {
   LogWriter.writeLog("[PDF] Tiff exception  " + e);
}

/* save data as image */ 
try {
   FileOutputStream fos = new FileOutputStream(fileName);
   fos.write(bos.toByteArray());
   fos.close();
   } catch (Error err) {
      LogWriter.writeLog("[PDF] Tiff error " + err);
   } catch (Exception e1) {
      LogWriter.writeLog("[PDF] Tiff exception  " + e1);
   }
}

In this tutorial you learned how to change CCITT data to a TIFF image, we have many more blog posts for Java developers working with image technology. Please feel free to check them out.

As experienced Java developers, we help you work with images in Java and bring over a decade of hands-on experience with many image file formats.

How to extract clipped images from PDF file in Java

IDRSolutions — Wed, 22 Jul 2026 14:51:10 +0000

This tutorial shows you how to extract clipped images from a PDF file in 5 simple steps using the JPedal PDF library. JPedal is the best Java PDF library for developers. Clipped images are raw images that have had their formats edited; this includes cropping, flipping, resizing and more.

How to Extract clipped images from PDF files?

1. Add JPedal to your class or module path. (download the trial jar).
Create a File handle, InputStream, or URL pointing to the PDF file
Include a password if file is password-protected
Open the PDF file
Iterate over the images on each page
Close the PDF file

and the Java code to extract clipped images…

File file = new File("/path/to/document.pdf"));
ExtractClippedImages extract = new ExtractClippedImages(file);
//extract.setPassword("password");
if (extract.openPDFFile()) {
    int pageCount = extract.getPageCount();
    for (int page = 1; page <= pageCount; page++) {
        int imagesOnPageCount = extract.getImageCount(page);
        for (int image = 0; image < imagesOnPageCount; image++) {
            BufferedImage img = extract.getClippedImage(page, image, true);
        }
    }
}
extract.closePDFfile();

Why use a third-party library to handle PDF files?

PDF files are a very complex binary/text hybrid data structure. The image data, color information, clipping and scaling details are all stored separately in a compressed format and need to be extracted and combined together.

A third-party library handles all of this for you automatically. In this example, we will use our JPedal PDF library. This provides an easy-to-use Java PDF APi so you can work with PDF files easily in Java.

Extract clipped images from a PDF file with JPedal

If you are looking to use JPedal to extract clipped images from PDF files, we recommend you start with these tutorials:

Why convert PDF magazines to HTML5?

IDRSolutions — Mon, 20 Jul 2026 09:40:11 +0000

In these articles, we talk about the advantages of converting your PDF documents to HTML5. Each point has a full supporting article with a more in-depth discussion on that point. Don’t forget to check back in the future, as we are continually adding to this list!

Gain control of your content – Many companies offer services where they will offer a viewer for your content on the basis that they host it for you. Not us; we let you take the credit for your content, along with the SEO that naturally comes with it.
SEO and the long tail – It is likely that you have a lot of back issues containing lots of well-written content full of all the right keywords. We let you convert this into a format that all search engines can understand, and allow you to take the credit for it.
The best ‘browser’ for your PDF content – Many services convert into a proprietary format (such as Flash) where you lose a lot of features (e.g. text selection). You can benefit by converting to a tried and tested format with billions of users.
Make it easy for foreign readers – Many services convert into a format with ‘fake’ (unchangable) text. We convert to real text that can be altered, for example by many web browsers that offer built-in web page translation.
Publish Everywhere – People are browsing content on an ever-increasing range of devices. Converting to HTML5 will give your content a consistent interface across a wide range of HTML5-capable devices. Read more…
Load quickly and save on bandwidth – One of the issues with PDF is that regardless of how much of the PDF you view, it is required to download the complete file. By converting to HTML5, your magazine readers only have to download the pages they actually read, and you can even create bespoke versions at different quality or zoom levels to optimise for mobile devices.
Measure content performance with analytics – Analytics is vitally important to give you performance data about your content, as well as the opportunity to learn about the demographics of your content readers. By converting to HTML5, you can enable analytics and start improving your content’s performance.

Want to learn more about the PDF file format? We have been developing PDF software for over 20 years!

How Does CCITT Compress Image Data?

IDRSolutions — Thu, 16 Jul 2026 11:23:26 +0000

How does CCITT compression work?

CCITT encodes black-and-white data. It does this by encoding runs of black or white pixels. We can do this in various ways (G31D/ G32D/G42D). They are also known as Group 3/ Group 4 compression. We explain how the most common type (G31D) works in detail below.

As most images contain more white than black, we assume that we start with white. For cases where we do not start with white, we add a marker at the start to show this.

If we encode black as value 1, we just set these bits in our decompressed data – we do not explicitly need to set white values (because it is binary, not setting a value to black means that it is white).

But sometimes, we find that there are more pixels that are black than white. Well, in this case, we can just invert the image (flipping bits is very fast) and then we get the best compression.

All we need is a flag (BlackIs1 in the PDF file format – its default value is false) to flag that the image data needs inversion to appear correctly.

How does G31D compression work?

This is the simpler form of CCITT to decode. Firstly, here are some keywords that would make it easier to understand how G31D works.

Key Terms

Pixel run- Usually 1-bit, 1 for Black and 0 for White. A block of pixels all the same.
Scan line– The width of data from one end of the page to the other.
Code Words– This contains information regarding what the data does, e.g., makeup or terminating.
Run Length– Block of either White or Black bits to be decoded/ encoded.
End of line(EOL)- Unique 12-bit code word used to determine the start and end of a scan line.

Return to control(RTC)- Six EOL code words occurring consecutively usually determine the end of the file. EOL & RTC would become more obvious in later blogs.

Overview of G31D

G31D CCITT is a variation of the Huffman keyed compression scheme. Essentially, to decode a G31D PDF file, a scan line is read in single-bit pixel runs. Each of these bits represents a number of white or black pixels.

The black and white run lengths alternate and vary in length making them uniquely identified when decoded, the maximum size of the run lengths is bounded by the maximum width of the scan line (page width).

More frequently occurring run-lengths are assigned to smaller code words while less frequently occurring run-lengths are assigned to longer code words. This is particularly useful as in a typical handwritten or printed document more short run-lengths are encountered than long run-lengths.

Encoding and Decoding Process

While still on the subject of pixel runs and run-lengths, it is important to mention facts about how pixel runs are encoded which in turn makes it easier to decode.
Pixel runs which are between 0 and 63 pixels in length are generally encoded using a single terminating code while runs between 64 and 2623 are encoded by a single make up code and a terminating code.
When the run length is above 2623 pixels, they are encoded using as many make up codes as needed and only a terminating code.

Firstly, a pre-calculated lookup table for both the black and white pixel runs has to be created against which the current data is compared. You want to be able to keep track of your current bit location in the scan line.

This is so that when a different bit is hit, be it black or white, the decoder can group the previous bits into a code word of either make-up (longer code words) or terminating (shorter code words) code words, which are then checked against the table and decoded as needed.

The make-up code word represents long run-lengths, while the short run-length is represented by the terminating cord-words. The sum of the length values of each code word makes up the run length. The process is repeated as new EOLs are hit.

It is also worth mentioning that each EOL usually starts with a white run-length code word. But there are some unusual cases where it does not follow the norm i.e. begins with a black run-length.

In this situation, the beginning of that scan is preceded by a zero-length white run-length code word. However, if 6 EOLs are hit consecutively, then this denotes the end of the file, i.e. RTC.

Advantages and Disadvantages

Advantages

Good compression of black and white data.

Disadvantages

Cannot optimise across lines or for multiple empty lines.
Takes a while to get to grips with the algorithm.

Do you need to read or write TIFF files in Java?

Our JDeli image library (the best enterprise-level Java image library for performance and efficiency) offers a range of advantages over ImageIO and alternatives for TIFF files, including:

prevents heap-related JVM crashes
reads 1-32 bit bilevel, grayscale, RGB, argb, cmyk, acmyk, ycbcr Colorspaces, and converts to sRGB BufferedImage
implements both Little and Big Endian Byte Ordering
decompresses uncompressed, CCITT group 3 and 4, Deflate/Adobe Deflate, LZW, Packbits
support for Single, Multi-file, Tiling, Planar (Chunky, Separated), Predictor, 16,32 bit floating samples
improve read performance
supports threading
superior image scaling algorithms

Learn more about JDeli, and try it yourself.

As experienced Java developers, we help you work with images in Java and bring over a decade of hands-on experience with many image file formats.

DEV Community: IDRSolutions

How to debug PDF files

Viewing Images in the PDF debugger

Debug Breakpoints

Xref Viewer Improvements

Learn more

PDF Performance and UX Issues in Web Publishing (Why PDFs Slow Down Websites)

Why PDFs Cause Performance and UX Issues in Web Publishing

Why Do PDFs Load Slowly on Websites?

Why PDFs Slow Down Websites (PDF Performance Issues)

PDF User Experience Problems (Mobile and Responsive Issues)

Why PDFs Don’t Work Well on Websites

Better Alternatives to PDFs for Web Publishing

How to Fix PDF Performance and UX Issues in Web Publishing

Comparing TIFF Compression Algorithms

JPEG

LZW

DEFLATE

Conclusion

How to find PDF page size in Java (Tutorial)

Why use a third-party library to handle PDF files?

How to find PDF page size in Java

and the Java code to find PDF Page size…

Further useful links

Measure content performance with Analytics – Why convert PDF magazines to HTML5?

Java CMYK to RGB Conversion – Speed Comparison

Introduction

Version 1: Using ColorConvertOp

Version 2: Manual Pixel Conversion

Performance Comparison

How to search a PDF file in Java (Tutorial)

How to search PDF file in Java

and the Java code to search a PDF…

Why can’t I just search the PDF file directly?

Related tutorials

iOS and HTML5: Gotcha with Absolute Positioning

Introduction

Issue on iOS Browsers

Investigating the Problem

Introduction of Parent Divs

Example of Current Output

Workaround and Conclusion

How to Convert CCITT data to TIFF image (Tutorial)

What is CCITT data?

CCITT data in PDF files

How to convert CCITT to a TIFF

and the Java code to write TIFF…

How to extract clipped images from PDF file in Java

How to Extract clipped images from PDF files?

and the Java code to extract clipped images…

Why use a third-party library to handle PDF files?

Extract clipped images from a PDF file with JPedal

Why convert PDF magazines to HTML5?

How Does CCITT Compress Image Data?

How does CCITT compression work?

How does G31D compression work?

Key Terms

Overview of G31D

Encoding and Decoding Process

Advantages and Disadvantages

Do you need to read or write TIFF files in Java?