DEV Community: IDRSolutions

How to view Multi-TIFF files in Java (Tutorial)

IDRSolutions — Wed, 09 Sep 2026 11:24:58 +0000

In this article, I will show you how to read and view Multi-TIFF files in Java. We already have an article on How to read TIFF images in Java, why not check it out!

JDeli helps you read, write and convert TIFF files in pure Java.

What is a Multi-TIFF file?

TIFF (Tag Image File Format) files are able to contain multiple images. This is what we would call a Multi-TIFF file.

How to view in Java?

First you need to read the images into Java. The standard JDK does not support multi-tiff images so you will need to use an additional library such as JDeli. JDeli is the best pure Java image library for performance and efficiency. You can only store one image in a BufferedImage, so JDeli returns an image count and a method to read each image.

final TiffDecoder tiff = new TiffDecoder();
final int imageCount = tiff.getImageCount(file);
BufferedImage image = tiff.readImageAt(currentIm, file);

Once you have the images as BufferedImages, they are easy to display in Java.

If you have read my previous post on How to view images in Java, then you already have an image viewer in Java or you can clone our Java Image Viewer GitHub repository. You can now modify it to view multi-TIFF images.

Additional code needed to support Multi-Tiff files in Java Viewer

First, you need to read each image in the file and display it. You can achieve this by keeping a count of the images in the file:

final TiffDecoder tiff = new TiffDecoder();
final int imageCount = tiff.getImageCount(file);

Then displaying them one by one with buttons to allow you to cycle through them, much like in our JDeli viewer.

final int currentIm = 0;
final JButton next = new JButton("Next image");
final JButton prev = new JButton("Previous image");
next.addActionListener(a -> {
  if (currentIm < imageCount – 1) {
    currentIm++;
    drawImage();
  }
});
prev.addActionListener(a -> {
  if (currIm > 0) {
    curentIm–;
    drawImage();
  }
});
// Add the buttons to the viewer
final JPanel multiButtons = new JPanel();
multiButtons.add(prev);
multiButtons.add(next);
add(multiButtons, BorderLayout.PAGE_END);

The draw image method would be one you’d use to set the image each time something like:

BufferedImage image = tiff.readImageAt(currentIm, file);
imageLabel.setIcon(new ImageIcon(image));

Now you can view all the images in your multi-TIFF file!

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 copy bookmarks from one PDF to another

IDRSolutions — Fri, 04 Sep 2026 15:51:57 +0000

JPedal already has the ability to read bookmarks from PDF files so now you can chain this functionality with our OutlineWriter to copy bookmarks from one PDF to another. JPedal is the best Java PDF library for developers.

How to Copy bookmarks using Java

Add JPedal to your class or module path. (Download the trial JAR).
Next, read the outline into a Document object:

// Read
final ExtractOutline extract = new ExtractOutline("source.pdf");
extract.openPDFFile();
final Document outlines = extract.getPDFTextOutline();
extract.closePDFfile();

Then, write the Document object to the destination PDF:

// Write
final OutlineWriter writer = new OutlineWriter("destination.pdf", outlines);
writer.writeOutline();

Copy bookmarks using the command line JPedal also provides a convenient command line method to copy bookmarks between PDF files:

java -jar jpedal.jar –copyoutline "oldfile.pdf" "newfile.pdf"

Working with PDFs can be troublesome. We have a list of different articles to help you understand the PDF format and maximise its functionality.

HTML and SVG Explained (Along with Use Cases)

IDRSolutions — Fri, 28 Aug 2026 14:40:01 +0000

In this article I will explain what HTML and SVG, how they’re related and which might be suited for your use case.

What is HTML?

HTML is the text-based language invented by Tim Berners-Lee at CERN to create web pages. It is displayed by Browsers (IE, Safari, Chrome, Firefox, etc).

The HTML language is defined by an international committee that releases a public specification. We are currently on HTML Version 5 (HTML5). You will find minor differences (which we often document on this blog) in support across browsers but no ‘major’ issues with HTML5 support in the major browsers.

How does HTML work?

This page you are reading is written in HTML but how does html code work? HTML contains both the text and instructions on how to display the text, links to images, etc. You might be wondering how HTML is used, I like to think of HTML as containing the page content, the structure of the page (HyperText Markup), and the style of the page (CSS).

You can write it from scratch in a text editor, but most people use tools to create it. There is now a huge range of dedicated tools to do this and many other applications (like the NetBeans IDE) also support it.

HTML5 Features

HTML5 had some major additions to the HTML features including:-

A Canvas (for writing action games and animation).
Support for video and sound
Offline support
Location functionality
SVG support (so SVG is now part of HTML)
Improved CSS support (which can also be used for animations and transitions).

HTML also includes support for fillable forms and interactive elements. The pages can contain JavaScript code and be dynamically updated.

HTML5 is the first version of HTML which we feel is good enough to make a decent conversion from PDF possible. You can try yourself and see what you think with our free PDF online converter.

Here is what HTML looks like as a page and the raw HTML code. The HTML is text but can include links to images and other pages.

If you’re working with PDFs and would like to convert them to HTML for your web applications, you can learn more about our product BuildVu. BuildVu is the best tool for converting PDF to HTML.

What is SVG?

SVG stands for Scalable Vector Graphics (although it can also include text and bitmaps). Such vector graphics do not lose their quality when zoomed or resized because they are scalable. This means that you define the content using simple text instructions, and when it is scaled, the browser will redraw it at the required resolution – so the Vector content is sharp with no pixelation at any resolution.

SVG Support

SVG has been around since 1999 (the joke was that it was the technology of the future and always would be). However, all modern browsers now support SVG either directly or as part of the HTML5 specification, so it is becoming increasingly common to use. It is based on XML and provides a text-based language to create shapes, text and embed images.

How does SVG work?

When SVG is used to build a page, more complicated pages can take longer to render. If you are interested in improving SVG files, my colleague Leon wrote a blog post describing six ways of optimising SVG files.

You can embed forms and video in SVG as Foreign objects, but in general, it lacks the wide range of features available in HTML5. It has arguably better drawing capabilities than HTML5 and when we compare the results of HTML5 and SVG from our converter side by side, the SVG generally looks ‘better’ (you can see 2 examples on this page to compare).

Here is what SVG looks like as a page and the raw SVG code. The SVG is text but can include links to images and other pages. You can use BuildVu to convert your PDFs to SVG for display on your own web applications.

More examples of HTML and SVG

Visit our BuildVu page to see more sample HTML and SVG files created from our PDF converter.

There is a very popular library called D3.js that has been used for some amazing things.

You can find an impressive example of animated SVG here (click and drag the nodes).

Conclusions – our take on HTML and SVG…

Our experience of HTML5 and SVG from developing our PDF converter has been that both have their strengths and weaknesses.

SVG is superior if you want a static display of vector content.

If you want to write animation, HTML5 has a canvas mode.

If you want to use JavaScript or Fillable forms HTML5 is the choice.

In practice, the fact that SVG is part of HTML5 means that you can use them together and this is the choice we have adopted for our PDF converter.

Comparing PNG Compression Algorithms

IDRSolutions — Thu, 27 Aug 2026 08:38:13 +0000

In this article, we will be comparing the different compression methods available for use in PNG images. To do this, we will be using our Java image library, JDeli. JDeli is the best pure Java image library for performance and efficiency. We will be comparing against file size, quality of output, and speed.

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

DEFLATE

DEFLATE was designed in the 1990s and is most commonly using in ZIP file archives due to its lossless property.

Using DEFLATE, the file size is reduced to 5.1MB taking around 6 seconds to encode. Since DEFLATE is lossless, the image quality is preserved and matches the original file.

QUANTISE

QUANTISE is a lossy compression technique that reduces file size by limiting the range of available colours. It is commonly used in PNG and GIF images.

Using QUANTISE, the file size is reduced to 3.5MB. QUANTISE is lossy, so there is a reduction in image quality, most noticeably in the range of colours which are output. It also takes around 6 seconds to encode.

Conclusion

In conclusion, there are not a great deal of options when it comes to different compression algorithms in PNG files. DEFLATE is a clear winner here as it reduces the file size with no loss of quality. QUANTISE would only be better when the smallest possible file size is necessary.

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 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!

DEV Community: IDRSolutions

How to view Multi-TIFF files in Java (Tutorial)

What is a Multi-TIFF file?

How to view in Java?

Additional code needed to support Multi-Tiff files in Java Viewer

How to copy bookmarks from one PDF to another

How to Copy bookmarks using Java

HTML and SVG Explained (Along with Use Cases)

What is HTML?

How does HTML work?

HTML5 Features

What is SVG?

SVG Support

How does SVG work?

More examples of HTML and SVG

Conclusions – our take on HTML and SVG…

Comparing PNG Compression Algorithms

DEFLATE

QUANTISE

Conclusion

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