The PDF

Cross-platform limitations of Mono.

noreply@blogger.com (TallComponents) — Mon, 28 Jan 2013 14:21:00 +0000

Some customers indicated that they were having issues running PDFRasterizer.Net on Mono. And although we do not officially support mono, we decided to do some experiments with it nonetheless.

Running a sample in MonoDevelop on Windows

So, we installed MonoDevelop, and we tried to run some of the PDFRasterizer.NET samples. This immediately led to the following error:

Error CS1566: Error reading resource file '…\TallComponents.PDF.Rasterizer_3.0.84.2\Code Samples\CS\ViewPDF\MainForm.resources' -- 'The system cannot find the file specified. ' (CS1566) (ViewPDF_vs2010)

In order to solve this issue we had to manually call resgen on all the .resx files. This allowed us to build the project, but when trying to debug it, we got the following:

Luckily, this appeared to be rather an issue with running the MonoDevelop debugger than anything else. Without debugging, things appeared to be fine, so we did not pursue debugging in Windows any further.

Running a sample in MonoDevelop on OSX

Then, we figured that we should also try things on Mac OSX. At first this gave some weird compile errors, like:

…/TallComponents.PDF.Rasterizer_3.0.84.2/Code Samples/CS/ViewPDF/MainForm.cs(35,35): Error CS0584: Internal compiler error: Method not found: 'TallComponents.PDF.Rasterizer.Document.ConvertToWpf'. (CS0584) (ViewPDF_vs2010)

This was strange because we used a sample that made no reference to any WPF functionality at all. It occurred to us however that this sample referenced a .Net 4.0 assembly, and we remembered some old blogs talking about MonoDevelop having issues with that. So we removed the .Net 4.0 PDFRasterizer.NET assembly and added the .Net 2.0 one instead. This looked quite hopeful at first, and interestingly we had no trouble running the debugger here:

But then we noticed that the evaluation banner was missing. The banner should have been there because we were running in evaluation mode. We started looking further. On OSX, PDFRasterizer.NET turned out to be plagued by basically 2 problems:

Some pages would render completely blank, or only partially.
Mono would just quit on some pages, leaving no further option to debug:

Compiling in MonoDevelop

In order to track this down, we decided to try and get our PDFRasterizer.NET sources compiled under MonoDevelop. We started doing so on Windows, soon to discover that the MonoDevelop compiler (3.0.5) has some limitations compared to standard Microsoft .Net. Amongst others:

it gives errors on vars.
it gives errors on extension methods
one needs to specify brackets for some #if evaluations

After “fixing” these, we went on to OSX with our sources. Here we discovered that some further issues were flagged. These were relatively minor, but it was certainly a surprise to find out that these differences exist between the PC and the Mac version of MonoDevelop. More so, because we also discovered that the Windows issues mentioned above were not flagged by the compiler on OSX at all. Both versions are the latest stable versions for both platforms, which at this point means 3.0.5 for windows and 3.1.1 for OSX.

Debugging

In any case, after having fixed these compilation issues, it became more or less possible to debug PDFRasterizer.Net on OSX. Apart from the occasional crash, we were able to identify the following 2 runtime issues:

there were runtime differences in casts from (negative) doubles to uints. Once we were aware of this, this was easy to fix.
The System.Drawing implementation on OSX turned out to behave differently with respect to clipping. In OSX the clipping area becomes empty at unpredictable times, leading to loss of graphics. If we turned off clipping altogether, we were able render additional graphics on some problematic pages , but part of the page would still be rendered incorrectly due to improper clipping handling.

The following pictures illustrate the latter. With clipping enabled, we would get the following on OSX:

Whereas with clipping entirely disabled, we would get:

Notice that the last result does show additional images (as it should), but also that the colors that are projected in the topmost images are wrong in both cases. This happens because clipping is used to draw the “intersections” of various colors. Clearly this goes wrong no matter whether clipping is turned on or not. For comparison, the same code – with clipping enabled - renders the following on MonoDevelop on Windows:

In itself this issue was already a showstopper for us. Unfortunately, having compiled the system on MonoDevelop itself also did not preclude the crashes that we encountered earlier. There were still PDF files that we were unable to debug at all, because Mono just quits on them.

Conclusion

All in all, it was very disappointing to discover that Mono is not as platform-independent as it claims to be, while also being very unstable on OSX. This means that it is currently impossible for us to have a workable solution for Mono on various platforms.

Apart for improvements in Mono itself, our hopes are now mainly on our own “TallBitmap” renderer, which will allow us to render PDF pages without relying on System.Drawing, and thus without depending on Mono’s implementation of this functionality on various platforms.

Making PDF rasterizer extensible - First design meeting

noreply@blogger.com (TallComponents) — Tue, 11 Dec 2012 13:32:00 +0000

Starting with version 4.0 of PDFRasterizer.NET, we will make our PDF render engine extensible in the sense that you can plug-in your own output device. This should enable developers to render (or convert) PDF to e.g. SVG, HTML5 or something else. This also serves an internal purpose; conversions that we already offer (e.g. render PDF to a GDI bitmap or XPS) will be implemented using this same plug-in API.

This article reports about our first design meeting. Much of what is included here will evolve over time. We will make small iterations and implement mutliple output devices to continuously validate the plug-in API. We will try to release these iterations as often as possible. To join the beta program, send a request to sales@tallcomponents.com. We welcome any feedback obviously.

Whiteboard notes

OutputDevice

The starting point of the plug-in API will be the OutputDevice class that must be specialized (inherited). It represents the device/format to which you want to render. By overriding a set of methods you implement your own output device (class MyOutputDevice). These methods will likely fall into one of two categories: 1. resource factories and 2. drawing methods. We will make the model such that you may choose to not implement everything and rely on the base class to simplify things if desired. A typical example is to not draw glyphs but rely on the base class to convert them to paths and render those instead. Another example is to support RGB only and have the base class do the color conversions for you.

Resources

The PDF imaging model includes the following resource types:

Paths
Fonts
Images
Color spaces
Colors
Patterns
Shadings
Groups

The OutputDevice class has virtual methods that return instances of these resources. These resource factory methods will be called when the given resource is required during rendering. The API model includes a base class for each resource type. The implentation of the override returns a specialization of the resource (e.g. SvgFont). If the resource is not supported, the virtual is not overridden.

Drawing

The second category of methods are the drawing methods. These are virtual methods of OutputDevice and can be overridden in MyOutputDevice. The drawing methods include at least:

DrawText
DrawPath (stroke and fill)
DrawImage

When these methods are called, the corresponding resources (e.g. Path when DrawPath is called and Font when DrawText is called) will either be passed with the method, or it will be accessible through the graphics state. This is yet to be decided.

Graphics State

Like many other imaging models, PDF has the notion of a graphics state. Here is part of what is included in the graphics state:

current transformation matrix (CTM)
current path
current font and font size
current color space and color (both for stroking and filling)

Operations inside a PDF document modify the graphics state in order to achieve the desired result when a drawing operation is performed.

How the graphics state will be part of the plug-in API is not sure yet. There several options:

We offer it as a base property of OutputDevice.
We offer overridables that will be called when the graphics state is modified. These methods can either be members of OutputDevice or of a class called GraphicsState that can be specialized.
We pass the relevant information to the drawing methods.
A combination of the three above.

Finally, there are operations that explicity save and restore the graphics state and there are operations that do this implicitly. This results in a stack of graphics states. Consequently, there may also be a property that reflects this stack while the current state is simply the top element of this stack.

Final words

As said, we will release iterations of the plug-in API in the coming weeks and months. To join the beta program, send a request to sales@tallcomponents.com.

Looking forward to your feedback!

Author: Frank Rem

TeamCity Security

noreply@blogger.com (TallComponents) — Tue, 04 Dec 2012 12:54:00 +0000

We were busy setting up a TeamCity server and an agent in order to get some continuous integration going. The setup we wanted was:

Have the TeamCity server setup in the cloud. We are not all working in the same office, so we need to have general access to it.

Run the agents locally in one or more of our offices. Fast hardware is not that expensive, and machines in the cloud cost money too. And after setting up these local machines, there is basically no need to attend them further.

A colleague had already set up TeamCity on our server, and I was going to set up the first agent locally. I thought that it was going to be simple to do this securely, but unfortunately I hit a few bumps.

Service Account

The first bump was a minor one. During the installation, I was asked which account the agent was going to run in. I could either specify “system account” (the default), or some specific account. I did not want to use system account, because that would give the agent administrative rights. Specifying another account however, gave an authorization error.

The way to solve this in Windows is rather simple, but you have to know how to do it. Instead of specifying a specific account, you will have to tell the installer to use the system account and let it proceed. Then, after it is finished, you can go to the services control panel and change the logon account for the TeamCity Build Agent service. If you pass the right credentials, you will see a popup that mentions that the account has been given the right to run as a service.

Agent Connection

When I fired up the new agent, it did not get a connection to the server. I looked in the logs. It said that the connection was lost. I remembered that the installer asked for an agent port. I looked up the documentation:

http://confluence.jetbrains.net/display/TCD7/Setting+up+and+Running+Additional+Build+Agents

It says: “Server should be able to open HTTP connections to the agent”.

I could not find an option to turn this off. I can understand that it is sometimes useful to give the server a direct link to the agent. But in this case, I would have to open up a port in our office to a machine in our own local network. I expected that this was just an option, and that I could turn the connection to the agent off. After all, other web based app’s can also do their thing without opening connections to their clients. The agent would just have to poll for work. But alas, no option.

And then I read: "Please note that by default, these connections are not secured and thus are exposing possibly sensitive data to any third party that can listen to the traffic between the server and the agents. Moreover, since the agent and server can send "commands" to each other an attacker that can send HTTP requests and capture responses can in theory trick agent into executing arbitrary command and perform other actions with a security impact."

The connection to the server can be configured to use https, but for the connection to the agent this option does not exist. All the settings that are configured in the TeamCity web GUI are passed over this link. This includes configured authentication information for the version control system.

In short: in order to do this securely, I would have to set up a VPN between the server and the agent.

This however would require changes at our remote server, and if not done properly it might disrupt it. And possibly I might have to configure our local router too, which could cause trouble on our local network. That was a bit too much for an initial setup.

Firewall

To be able to deal with this, I set up the agent firewall so that it only accepts connections for a single port from our TeamCity server. I also limited outgoing connections to one or two ports on our server. Our internal network is now invisible to the agent machine, and if it gets compromised, there is nowhere to go (assuming an attacker cannot intercept responses to our server).

Also, we avoided the standard TeamCity mechanism for checking out sources. Its server-side checkout might send sources to the agent out in the open, while for its agent-side checkout it might tell the world about some credentials used for our version control system.

Instead, we let the agent check out the sources over https via TortoiseSVN, using locally stored credentials. Sure, if the machine gets compromised over the agent link it may be possible to find them, but given the firewall rules it will be hard to get them out.

And finally, we made sure that the team city agent does not have write access to our version control system. A matter of damage control.

COMPROMISE

I know that this setup is not ideal, and it may well be that we go for a VPN solution after all. But a VPN raises questions too. Our TeamCity server is basically a “public” machine. If it gets compromised we will not be happy, but it will just be the server. If it were part of a VPN on the other hand, the situation might be worse: via the compromised server it may be possible to easily reach other machines within the VPN and compromise these too.

In any case, what amazes me the most is that a well-known system like TeamCity requires a connection to the agent. Without it, we could just have used https to the server and be done with it. No VPN setup, no special router configuration, no firewall restrictions (or at least less severe ones), and no restrictions on using TeamCity’s check-out mechanism.

It surely would have made things a lot simpler.

Author: Marco Kesseler

WinRT edition of PDFRasterizer now 3-4 times faster

noreply@blogger.com (TallComponents) — Thu, 15 Nov 2012 13:51:00 +0000

We have just released maintenance update 4.0.0.4 of PDFRasterizer.NET. The most significant changes are:

There is now an unsafe variant of the WinRT edition to speed things up. We measured 3-4 times faster rendering! We are still investigating implications for the Windows 8 App Store Certification process. Any feedback is welcome!
When drawing using the WinRT edition, you can now cancel draw jobs in progress. You typically do this when flipping away from a page before it has finished.

To join the beta program, just send a request!

Rasterizing PDF on WinRT

noreply@blogger.com (TallComponents) — Thu, 18 Oct 2012 07:29:00 +0000

Today we released a beta version of PDFRasterizer.NET 4.0 (4.0.0.3) that includes a WinRT edition. It took us a little bit longer than we hoped for. I want to explain why. In addition it also includes a Silverlight 4 edition. If you are interested, send a request to sales@tallcomponents.com and we will provide download instructions.

Known restriction of current beta (4.0.0.3)

This version does not support:

Soft masks.
Non-embedded fonts. This is related to not having access to system fonts from WinRT.
Shadings other than gradient, radial, function based (shadings are slow)
IccProfiles. We revert to the alternate colorspace.
Special colors (such as CMYK) are not entirely correct. E.g. too bright or too pale.
Blendings

So why did it take us so long?

The main problem with rasterizing PDF documents are the restrictions of the graphics API of WinRT itself. Amongst others, it only supports rectangular clipping paths. This alone is a showstopper.

We struggled with similar problems when using GDI+ or WPF as the graphics API. But their shortcomings always came down to not being able to render edge cases (exotic shadings and blend modes). But even then we could revert to a bitmap-based workaround. If a graphics API is able to render to bitmaps, one can implement extensions in terms of operations on these bitmaps. This is not an ideal solution (espcially w.r.t. printing), but it often works well for on-screen solutions.

This bitmap-based solution is unavailable when developing for WinRT. There is no equivalent for GDI+ code like this:

// Create bitmap
Bitmap bitmap = new Bitmap(500, 500, PixelFormat.Format32bppRgb);

// Create graphics object from bitmap
Graphics graphics = Graphics.FromImage(bitmap);

// Create pen
Pen blackPen = new Pen(Color.Black, 3);

// Create points that define line
Point point1 = new Point(100, 100);
Point point2 = new Point(500, 100);

// Draw line to bitmap
graphics.DrawLine(blackPen, point1, point2);

When developing for WinRT, you can create a WriteableBitmap which can only be manipulated by setting pixel values. There is no way to e.g. stroke or fill a path.

Because of the shortcomings of GDI+ and WPF, we had considered developing our own graphics engine before. WinRT gave us that last push.

On May 15, I sent off an internal e-mail to the development team announcing a new internal project. Here is the first part of this e-mail:

Until now we relied heavily on the graphics API as provided by Microsoft such as GDI+ and WPF for rendering PDF documents. Because of this we were not able to render all PDF features such as complex shadings and complex blend modes. With the introduction of new platforms such as WinRT and Silverlight, even less exotic graphical features have become unavailable. Because of this we have decided to develop an internal module (100% managed code) that frees us from the graphical capabilities that Microsoft decides to offer. Let's call this module TallBitmap.

The graphical feature set of TallBitmap should cover all graphical features of PDF such as:
- path construction and painting (PDF spec 4.4)
- fill rules (non-zero winding number, even-odd)
- clipping
- patterns (PDF spec 4.6). Including shading patterns.
- transpareny and blend modes (PDF spec Chapter 7)
- clipping
- dash patterns
- join style / cap style
- images (PDF spec 4.8). Note that the library does not have to include decoding. The library assumes that the images have been decoded.

For five months, two of our engineers spent 50% of their time implementing TallBitmap. They worked in sprints of five days and alternated this with support.

Today, this work paid off when we released a WinRT edition of our PDF render engine that is based on our internal module TallBitmap.

Frank Rem, CEO

WinRT edition of PDFRasterizer.NET available

noreply@blogger.com (TallComponents) — Wed, 17 Oct 2012 14:08:00 +0000

We have just released a PDFRasterizer.NET 4.0 Beta that includes a WinRT edition. To join the beta group, send a request to sales@tallcomponents.com.

PDFWebViewer.NET Discontinued

noreply@blogger.com (TallComponents) — Mon, 01 Oct 2012 12:09:00 +0000

As of today, we have discontinued PDFWebViewer.NET 1.0. We will not release version 2.0.

Here is why:

PDFWebViewer.NET's sales was neglectable compared to flagship products such us PDFKit.NET and PDFRasterizer.NET while the support and maintenance effort was unproportionally high.
We strongly believe in separation of concerns when it comes to designing software components. PDFWebViewer.NET does not meet this design criterium.

The first reason is obvious. Let's elaborate on the second one.

PDFWebViewer.NET is an ASP.NET control that provides a browser-side view on a server side PDF document. It implements features such as zooming, panning, interactive links, etc.

On the browser side, we need to support different types of browsers and different versions of individual browsers. Nowadays this includes browsers on mobile devices in addition to browsers on desktops. But also, server-side we need to support different types of web application frameworks such as plain vanilla ASP.NET, MVC and what will be released next.

In contrast to this dependency on browser flavors and web application frameworks, components such as PDFKit.NET and PDFRasterizer.NET have a fully UI-less API and thus are much less coupled to technologies that come and go.

In order to not spread ourselves too thin, we need to focus on core functionality. That is why we decided to discontinue PDFWebViewer.NET 1.0 and not release its successor 2.0.

Existing Customers

Internally, PDFWebViewer.NET 1.0 and WebViewer.NET 2.0 are build on top of PDFKit.NET 4.0 and PDFRasterizer.NET 3.0. We have released the source code of both major versions on CodePlex under the Microsoft Public License. You will see that the downloads include the PDFKit.NET 4.0 and PDFRasterizer.NET 3.0 assemblies. Contact support to convert your PDFWebViewer.NET licenses to PDFKit.NET 4.0 and PDFRasterizer.NET 3.0 licenses at no cost.

Download source code:

Windows 8 Release Preview – back to earth

noreply@blogger.com (TallComponents) — Thu, 28 Jun 2012 15:19:00 +0000

Hurray, we got a workaround for the problem of the previous blog. This works:

IRandomAccessStream stream = await file.OpenAsync(FileAccessMode.Read);

for (ulong i = 0; i < stream.Size; i++)
{
stream.Seek(i);

byte[] data = new byte[1];

await stream.ReadAsync(data.AsBuffer(), 1, InputStreamOptions.None);

    if (stream.Position > stream.Size)
    {
       // Never happens, which is as expected.

}

The credits for finding this go to Gionata from paperlit.com. Thanks!

Note that the main difference appears to be:

IRandomAccessStream stream = await file.OpenAsync(FileAccessMode.Read);

As opposed to:

Stream stream = await file.OpenStreamForReadAsync();

Weird, eh? One would say that both expressions are basically synonymous.

Well, this means back to work, were it not for the summer holidays…

Author: Marco Kesseler

Windows 8 Release Preview – to boldly go where…

noreply@blogger.com (TallComponents) — Tue, 12 Jun 2012 12:37:00 +0000

Windows 8 continues to amaze me. I recently upgraded to the Windows 8 Release Preview and tried to run one of our projects. After dealing with some of the changes, it returned an error that I could not quite place.

Debugging revealed that stream.ReadByte() would sometimes leave the stream position far beyond the end of the stream. This only happened in combination with a call to stream.Seek().

So, I wrote the following test. It opens a file, and then tries to seek increasingly further in it – but not beyond the end - and at all these positions it reads a single byte. As soon as this leads to a position beyond the end of the stream, it prints how far from the end of the stream we were actually trying to read.

var file = await fileOpenPicker.PickSingleFileAsync();

if (file != null)
{
Stream stream = await file.OpenStreamForReadAsync();

   for (long i = 0; i < stream.Length; i++)
   {
      stream.Seek(i, SeekOrigin.Begin);

      if (stream.ReadByte() >= 0)
      {
         if (stream.Position >= stream.Length)
         {
            System.Diagnostics.Debug.WriteLine(stream.Length - i);
         }
      }

}
}

And the result is: things start to go wrong at 8192 bytes before the end of the stream. For every file I tested. Always.

Now I am starting to become a bit paranoid. Is it just me? Am I doing something wrong? Is my metro system hosed? I have Googled for this issue, but found nothing. Am I the only one trying to do these things on Windows 8? I cannot believe it.

Author: Marco Kesseler

Searching Text and Recognizing Columns

noreply@blogger.com (TallComponents) — Tue, 01 May 2012 09:10:00 +0000

In order to find text, it is important to scan content in the correct order. For example, take a look at the following piece of text:

We will read it as follows:

The National Transportation Safety Board said a 12-member team....

We definitely do not read it like this:

The National Transpor- House Speaker John tation Safety Board said a Boehner said ...

From this it is clear that text in its nature is a sequential stream of information. In order to get a correct search result, we should preserve this sequence.
Ok, it is quite easy for me as a human being to recognize the columns in the text. My recognition system has been practiced in doing that for a long time (still need to practice to apply different image filters directly in my brain). But what about machines? How does software recognize layout structure of a text within a PDF file?
Most PDF documents do not store this layout information. If you look inside the document you can barely distinguish columns, paragraphs, sentences or even words. You can however extract runs of characters and their coordinates within a page.
So how to obtain the information about the text strcture? In this article we are going to build word position histograms in order to recognize columns.

Using histograms as a first guess to finding columns

How we can make the initial guess? Let’s take a look where the words begin. All the words on the left side of the column have the same X coordinate. Therefor it should be interesting to build a histogram that shows the frequence of a word start along the horizontal axis.
In order to build the histogram I use PDFKit.NET as it allows to extract all glyphs on the page. The glyphs are used to get the position of each word and based on that data I can construct the histograms. From the picture below you can see how the histogram corresponds to the page. The histogram clearly shows two peaks. These peaks are probably the left edges of the columns.

The histogram of the following page has six big peaks and we conclude that the page has six columns.

In fact we can see not only the amount of the columns but some more additional information. Notice that there is almost no noise between the first peak and the second one.

That happens because the first column doesn’t intersect with the second one.

However there is some noise distributed over the rest five columns. Moreover the noise between the second and the fifth column has almost the same level.

This noise is caused by the text under the picture which is not divided into columns. The same can be observed from the noise between the fifth and sixth columns.

Download this Visual Studio .NET project to construct histograms yourself.

Author: Sergey Zavoloka

Rasterizing WinRT

noreply@blogger.com (TallComponents) — Wed, 25 Apr 2012 08:31:00 +0000

Earlier we posted that creating WinRT editions should be painless.

Well, today we rewrite that “should”. Our earlier blog mostly talked about deployment, assuming that the WinRT graphical API would basically be similar to the non-Metro API. This assumption turned out to be incorrect. WinRT does not offer GDI+ (System.Drawing), nor does it offer WPF (Windows Presentation Foundation) in all its glory. It does appear to be remarkably similar to the SilverLight API, but there are some serious differences.

Clipping: similar to Silverlight, all graphical elements have a Clip property. In WinRT however this is no longer has the general Geometry type, but it has been restricted to a RectangleGeometry. There is also no OpacityMask in WinRT. At this point it is not clear to us how we can achieve any form of non-rectangular clipping (which is ubiquitous in PDF documents).
Images: similar to Silverlight, it is possible to use a WritableBitmap to fill images with binary pixel data. In Silverlight, one can use SetSource() to specify a stream of ARGB values (bytes). In WinRT however, one needs to assign an instance of IRandomAccessStream. It is not clear to us yet how we can create such an instance for (for example) a stream of data. There appears to be no standard solution for using a MemoryStream as an IRandomAccessStream, which looks like a serious omission to us. We tried to create our own simple implementation based on a MemoryStream, but alas, so far this just started throwing unclear exceptions (to be continued some other time…)
Radial Shadings: WinRT has no Radial shadings

To illustrate this: we have been able to arrive at a first internal version of PDFRasterizer.NET for metro, using some stubs for various parts. We obtained the following result:

While Adobe Reader shows this file as:

We expect that we will be able to solve (or work around) the image loading problems if we look into this a bit further. And for now we assume that radial shading is just something that just did not make it into the preview release. The Metro Clipping issue is quite serious however, if it is not an accidental restriction. The same applies to the omission of the OpacityMask.

I should also mention that the depicted rendering differences are not all related to the issues mentioned above. We simply did not have the time yet to implement some of the more complex shadings. This mostly applies to the bottom part of the page. This also means however, that it is not yet entirely certain that we will not encounter additional issues there.

Interestingly, Windows 8 comes with a metro-style PDF viewer. This shows this document as follows:

This shows the following:

The radial shading at the bottom left is also missing in the built-in viewer. This seems to support our assumption that radial shading is just something that just did not make it into the preview release.
This viewer does not suffer from the clipping restriction. This seems to suggest that it either uses some internal features that we do not have access to, or it uses an different platform altogether, possibly C++ and DirectX. The problem with DirectX however is that there is no C# binding for DirectX and even if there were it cannot be mixed with XAML for as far as we know. So at present this is no option for us.

At this point, we feel that the preview release of WinRT is still a bit too limited to actually implement a full-blown viewer for it. We are driving the metro but some of the stations are missing.

Author: Marco Kesseler

A Second Office in Russia – Part 1

noreply@blogger.com (TallComponents) — Mon, 19 Mar 2012 10:18:00 +0000

A huge step for every business owner is to hire that first helping hand. Until that point you run your business as lean as possible: by yourself. Because of that first employee you need to deal with legal obligations, income taxes, salary negotiation, dividing tasks, etc. And not to forget, you suddenly are a bit of a boss.

Something similar holds for a second office.

The first minute

Our second office started March 1st, 2012. Here is a Skype video screenshot of the first minute. I am in The Netherlands, Tegelen and my time is 3 AM in the night. My new colleagues are in Russia, Novosibirsk Academgorodok (6000 km away) and their time is 9 AM. How do you like my bed look?

From left to right: Alexander, Konstantin, Alex and me

How it started

During summer, we have our lunch in the garden whenever possible. During one of those lunches in summer 2011, I was telling about my previous experiences 4 years ago with a remote team in Poland. I deliberately did not call it a second office because it never felt that way. Í was just hiring people from another company. The mission failed miserably. Mostly because I selected a company based on the promises of management and I trusted too much on their selection skills.

Again we were in the position that the company needed more developers. I felt that we were not keeping up with support. Sergey started working for TallComponents early 2011 after he moved from Russia to The Netherlands. He suggested that a friend of him, might be able to help me bootstrap this idea.

Alex and I met on Skype. I expressed that I wasn't looking for outsourcing work. Instead, I was looking for new colleagues. That appealed strongly. Alex came up with a team of three developers (including himself) that already knew each other intimately from college and did many development projects together. That sounded like a jump start.

Pilot

My girlfriend convinced me to do a pilot in The Netherlands. Fly over the guys and have them work on a project for a few weeks. This way, we would get to know each other both personally and professionally. I agreed with the candidate team that they would visit the Dutch office for two weeks. We set a goal: at the end of this period we should have a feature complete XPS to PDF converter with automated tests in place. The converter would be build on top of PDFKit.NET 4.0. This way I would not yet have to expose any source code to the team.

But I had a second plan. A business case had emerged that required a Silverlight edition of our PDF render engine. I decided to change the goal and have them port our PDF render code to Silverlight. This plan had one drawback: I had to expose our source code.

The team visited our Dutch office. On Monday morning, they entered the office. Chilly atmosphere. Uncomfortable talks. It didn’t feel good. I quickly changed the goal of the pilot back to the XPS to PDF converter. An hour later I told a long time employee about my decision and he started working on getting our PDF render code ready for Silverlight.

Later on I learned that Russians and Western Europeans behave totally different in a first meeting. It was an interesting lesson.

They did an excellent job. At the end of the two week pilot we had a working XPS to PDF converter and automated tests were in place. The team expressed that they were looking forward to work at TallComponents. And I wanted to have them on board. The next goal was to have the Russian office up and running March 1st, 2012.

Coming up

In Part 2, I will blog about my one week visit to Novosibirsk during which we prepared the office for the March 1st start. In a part 3, I want to share our collaboration challenges that come with a second office.

How to PEVerify Silverlight

noreply@blogger.com (TallComponents) — Thu, 16 Feb 2012 14:56:00 +0000

Ever ran PEVerify on a Silverlight assembly, and you got something like this?

[….many errors snipped…]

[IL]: Error: [D:\SVN\Components\bin\PDFRasterizer.NET\SL4\STANDARD4\TallComponents.PDF.Rasterizer.dll : TallComponents.Images.ImageProperties::.ctor] [HRESULT 0x80070002] - The system cannot find the file specified.

[IL]: Error: [D:\SVN\Components\bin\PDFRasterizer.NET\SL4\STANDARD4\TallComponents.PDF.Rasterizer.dll : TallComponents.Images.ImageProperties::get_TransparentColor] [HRESULT 0x80070002] - The system cannot find the file specified.

[HRESULT 0x80070002] - The system cannot find the file specified.

196 Error(s) Verifying TallComponents.PDF.Rasterizer.dll

Look in Program Files (x86)\Reference Assemblies\Microsoft\Framework\Silverlight\v4.0 (or whatever version you are using). Copy all assemblies to the same folder as your Silverlight assembly. Run PEVerify again, et voila:

All Classes and Methods in TallComponents.PDF.Rasterizer.dll Verified.

Assuming of course that you use an up-to-date version of peverify and that your assembly in fact does not contain any issues that PEVerify checks for.

Author: Marco Kesseler

Help, my images have white stripes

noreply@blogger.com (TallComponents) — Thu, 09 Feb 2012 13:16:00 +0000

In PDF, there are often images that actually consist of a collection of smaller ones, neatly put next to each other.

Rendering these images seems easy enough in GDI+: just call the proper “DrawImage” method and that’s it. But then you discover that there are ugly stripes between the images.

What happens is the following: when the first of these images gets drawn, its edges are interpolated with the background color around the image, which is white at that point. This results in a smooth border that is almost completely white at the very edge. Then, when the neighbouring image gets drawn, its edges get interpolated again, this time with the lighter edge of the previous image.

All in all, the image edges get interpolated against a background color that actually should never have been visible in the first place.

A simple solution is to fool GDI+ and tell it that we do not intend to draw a single image, but that it is part of a tiling pattern where the images get flipped over both the X-axis and the Y-axis:

using (System.Drawing.Imaging.ImageAttributes attrs = new System.Drawing.Imaging.ImageAttributes())

{

    attrs.SetWrapMode(System.Drawing.Drawing2D.WrapMode.TileFlipXY);

    graphics.DrawImage(

                           bitmap,

                           rectangle,

                           0, 0, width, height,

                           System.Drawing.GraphicsUnit.Pixel, attrs);

}

The image will be clipped against the given rectangle, so we won’t actually see any tiling happening, but GDI+ is now aware that the edges of the image are not drawn against a white background. In fact, it still interpolates de edges of each image, but it now does so against the edges of the neigbouring (but invisible) tile, which has the same colors (that is why we need flipping):

There are of course also drawbacks to this technique: if an image has a very sharp transition near its edge, one still sees the interpolation happening. See the “belly” of the “S” below.

However, if we use some heuristics to avoid the tiling technique in certain cases we can largely avoid such issues:

We must admit that we are probably not the only ones that thought of this. The following image is from Adobe Reader X. It appears that it does something similar – see the top edge –, although of course it is impossible to say whether it really uses the same technique.

Author: Marco Kesseler

Problem saving WPF as XPS.

noreply@blogger.com (TallComponents) — Thu, 02 Feb 2012 11:42:00 +0000

It turns out that XPS is sometimes trickier to generate than plain WPF elements.

We recently encountered a PDF file, that we were able to convert to a WPF FixedDocument instance, and view in a standard DocumentViewer:

However, when we used “Save as XPS” from the DocumentViewer window and tried to view the resulting XPS file, we got the following:

Closer inspection of the XPS file revealed that the page contained the following snippet for one of the text strings on the page:

The “Indices” attribute suggests that it holds the indices of each glyph in a font, but it commonly specifies the exact placement each glyph. The snippet above does this too. It specifies the placement of the next glyph relative to the previous one.

During the computation of the location of one character, we arrived at a position that was slightly offset to the left compared to the previous one. And so we produced the offset –1. In PDF this is not necessarily an error. In principle, this technique may be used to place several glyphs on top of each other in order to produce a single “combined character”, such as characters with diacritical marks or ligatures. In practice however, negative offsets are often avoided.

This particular case was a bit unclear. It involved some invisible text that consisted of seemingly random codes. Consequently, we chose simply to ignore the negative offset:

And now all is well again. It remains to be seen however if we encounter cases where such negative offsets are more critical. The most interesting part is of course that having a valid WPF instance does not guarantee that the resulting XPS document is alright.

Author: Marco Kesseler

WinRT and C#/.NET Components

noreply@blogger.com (TallComponents) — Mon, 23 Jan 2012 09:31:00 +0000

Monday morning started with the following question in the sales inbox:

“Do you plan to support Windows 8 Metro Style App’s using the WinRT API’s with a product like PDFRasterizer.NET? If so, when? We are in development now, so would you have a preview version that we could use during development?”

This was the first request after Microsoft announced WinRT during their Build conference in Anaheim CA, September 2011. I googled around trying to quickly understand the implications of providing WinRT editions.Here are my first quick findings (in random order).

#1: WinRT includes the .NET framework.

So we do not have to port our C# code. Good thing! The included framework is .NET 4.5. To target this version we need Visual Studio .NET 2011. Caveat: VS 2011 only runs on Windows 8.

#2: WinRT introduces a new file type: .winmd

We can decide to either output a single .winmd including both API description and implementation. This is required to support non-managed languages such as JavaScript and C++. Or you can ship a pair of files: a DLL containing the implementation plus a .winmd containing the API description only. If you do this, only managed clients can use your component. Since it seems trivial to output a single .winmd (it is a project setting), I do not see a reason to restrict ourselves to managed clients only.

#3: All public classes must be sealed

We definitely don’t want this restriction to propagate to non-WinRT editions. We already have too much #if constructs cluttering our code so I prefer to post-process our normal assemblies to achieve this. We use DeepSea Obfuscator to obfuscate our assemblies. In fact we use it for much more such as changing accessiblity and injecting module assemblies, I called DeepSea’s CEO Ewout Prangsma (we happen to co-own this company) and asked whether DeepSea supports sealing classes in a compiled assembly. It does! In fact it already consumes .winmd files!

Looks like adding WinRT editions to our releases should be painless. In the next days we will do some experiments and build a small Metro app that renders PDF documents.

Author: Frank Rem

No one needs more than 6 MB of Silverlight

noreply@blogger.com (TallComponents) — Wed, 04 Jan 2012 17:48:00 +0000

How small should Silverlight be?

I am not talking about market share, nor am I comparing it to HTML5. No: how small should it be compared to its big brother WPF?

If you start porting existing WPF code to Silverlight, you will soon discover that quite a bit is missing. MSDN does not help here. It does list some differences, but it does not say anything about the issues below.

First of all, Silverlight lacks method overloads. These are often easy to solve, but as we like to share our code as much as possible, we now have to add some comments warning against using the old overloads, as any non-suspecting programmer might easily break things again when working on non-Silverlight projects that share the same code. Luckily it is often possible to use extension methods to add the missing overloads.

Other easy fixes include the lack of collections like (the non-generic) ArrayList or HashTable.

Then there are missing parts that have an “existing” alternative. In WPF there are two ways in which graphics can be constructed. It is possible to “draw” in a constructive/declarative way by adding graphical elements as Children to other elements. But it is also possible to draw in a more imperative way using a DrawingContext. You will have to rewrite your code if you used the latter, because Silverlight only supports the former (yes, we used DrawingContext, because it resembles GDI+ more, which is were we came from...).

There are also missing parts that have a “new” alternative. There is no XmlNode. You will have to use the Linq variant XNode. And XElement, and XAttribute, and XDocument, and etc. So bascically all the old functionality is there, but you “just” need to use the new classes. If you have a lot of code, the best way is to recreate your own “Xml” classes and map all functionality onto the Linq “X” variants.

Cloning is also (largely?) missing. You will have to implement it if you need it. And you probably will, because sharing Graphical elements in a visual tree will lead to exceptions. It boggles the mind why someone decided to omit cloning without tackling the sharing exceptions in the visual tree.

And then there is missing functionality for which there is no alternative. At one point, we needed to take the intersection of two geometries in Silverlight, and we found no way to do it. Of course we encountered this after doing all of the above. It never occurred to me that something like this would not exist in Silverlight. Some suggested using a geometry group, but these only provide unions, not intersections. It almost proved to be a show-stopper.

But we were lucky: we only needed the intersection of two regions for clipping. It turned out that one can put a canvas with a particular clipping geometry an use it inside another canvas with another clipping geometry. And if you then draw inside the inner canvas, all graphics get clipped against both, which is effectively the same as clipping against the intersection of both geometries.

I am now left wondering whether Microsoft actually foresaw this use of nested canvases, and decided that geometry intersection was therefore not required, or whether this was just an accidental omission.

What is it with Silverlight and being small? I suspect that many programmers write “glue” code in order to port existing code to Silverlight. This all adds up to the size of their own apps, which have to be downloaded over and over again. It seems far more sensible if Microsoft were to write this glue code once and put it in Silverlight itself. I mean: what does it matter if the Silverlight installer is 6 MB or 30?

I suspect that only programmers care. Praising the small size of Silverlight is like saying that 640 KB should be enough for anybody in a time that half the world is busy downloading movies over the internet.

Author: Marco Kesseler

What the Hack?

noreply@blogger.com (TallComponents) — Mon, 29 Aug 2011 09:20:00 +0000

A while ago, we got notified that PDFRasterizer.Net was hacked. Some guy – it probably is a guy – posted it at a Czech forum. I could not actually access the hacked software, as I did not have sufficient rights, but it was obvious. There were even requests for hacking some of our other libraries.

I created an account and posted a reply pointing out that this guy was a scoundrel. I included a link to our own website and I reported the post to the web site owner.

They did not like it:Darn.

Of course we can start legal actions against every site that does this. But that will cost a lot. No self-respecting company is going to shop on these forums for our software. And the boys that do look there are not going to buy anything from us period.

So we are telling ourselves that this is free publicity, and… some form of recognition. We must be doing something right if we get their interest.

Author: Marco Kesseler

Opacity masks in WPF – how can we use them imperatively?

noreply@blogger.com (TallComponents) — Thu, 07 Jul 2011 14:10:00 +0000

During the implementation of PDF soft masks in our WPF version of PDFRasterizer.NET we realized that there is little information about WPF opacity masks on the internet. The only information that exists is about applying masks declaratively (in XAML) but it is unclear how to use them imperatively.

I assume that you are familiar with the concept of WPF opacity masks, otherwise you can read about it here.

There are two approaches how an opacity mask can be applied to an instance of the Visual class. The first approach is to assign an opacity mask to a drawing visual instance. This approach has several restrictions that reduce its flexibility. First of all, the mask is applied only when the Close() method of the DrawingContext is called. Hence, only one mask can be applied. And secondly, the mask is applied to whole the drawing, not to a particular part.

The second approach is to use a pair of PushOpacityMask and Pop operations (let’s just call it Push/Pop below). These are performed on a drawing context instance. Msdn offers hardly any information on this. This is the only information we could find:

“The mask is applied to all subsequent drawing commands until it is removed by the Pop operation”

Internet resources do not give any additional description of the Push/Pop approach either.

Let’s try to understand how Push/Pop works. In order to do this we will perform several experiments. We need four pictures. The first is shading.

The inverted shading:

The next picture is a nice background:

And a red circle to draw on the foreground:

What I’m going to do is to draw the background with the opacity mask and the red circle on the foreground with the inverted opacity mask.

//create an opacity brush
ImageBrush opacityMask = new ImageBrush();
opacityMask.ImageSource = new BitmapImage(new Uri("mask.png"));

//create an inverted mask
ImageBrush invertedOpacityMask = new ImageBrush();
invertedOpacityMask.ImageSource = new BitmapImage(new Uri("invertedMask.png"));

//load an image from file
ImageSource clouds = new BitmapImage(new Uri("clouds.png"));
//load the red circle from file
ImageSource redCircle = new BitmapImage(new Uri("redCircle.png"));

DrawingVisual drawingVisual = new DrawingVisual();
DrawingContext dc = drawingVisual.RenderOpen();

//push the opacity mask
dc.PushOpacityMask(opacityMask);

//draw the background
dc.DrawImage(clouds, new Rect(0, 0, clouds.Width, clowds.Height));
dc.Pop();

//push the inverted opacity mask
dc.PushOpacityMask(invertedOpacityMask);
//draw the red circle
dc.DrawImage(redCircle, new Rect((clouds.Width – redCircle.Width)/20, 0, redCircle.Width, redCircle.Height));
dc.Pop();
dc.Close();

The result:

Looks nice, isn’t it? That’s what I wanted. Notice, that we should call Pop() before we draw the red circle, otherwise the first mask would be applied to the red circle as well.

But it is not entirely clear for which area the mask is applied. Is it scaled to fit the whole image?

To take a better look at the matter I’ll take a transparent background image and draw a red square on it with the inverted shading as an opacity mask.

Here is the result:

If the opacity mask is scaled to fit the picture, the red square should be fully opaque as it is placed in the fully dark part of the shade. We can see it from the schema below.

Apparently the opacity mask was applied to the red square only. The schema in this case should looks like this:

It looks like the opacity mask is being scaled to fit object which are drawn within Push/Pop scope. We will verify this by drawing a number of objects. You can see the result below:

Our assumption is correct – the opacity mask is scaled to fit the area where the objects have been drawn. The schema below represents it.

Conclusion

We have gained some insight how the WPF opacity mask can be used imperatively. We learned:

If you want only one opacity mask to be applied to the whole Visual, you can assign an opacity mask to the Visual instance.

If you want to apply more than one mask to the Visual, you should use a pair of PushOpacityMask and Pop operations on a drawing context instance.

If you want to apply an opacity mask to a particular set of drawings on the Visual, you should draw the set within the scope of PushOpacityMask/Pop. Keep in mind though, that the mask will be scaled to fit the drawing area of the entire set of elements.

You can also apply the opacity mask to each drawing individually and this will produce a different visual effect.

Raising the Bar

noreply@blogger.com (TallComponents) — Thu, 30 Jun 2011 13:32:00 +0000

I wanted to have a QR barcode on a PDF form, and I wanted it to get dynamically updated with the value of another form field. Sounds reasonable I think. Does not sound hard either. Let’s have a look at some trial and error in Adobe Acrobat.

First step: I happily started Acrobat X and chose “Add Barcode Field”. It greeted me with the following message:

I just ignored this. I am not doing any paper forms processing, am I? I am just adding a barcode to an electronic form. So, I added the Barcode field, set its “Symbology” to “QR Code” and pointed to the field “Text2” for its value.

And sure enough, in Acrobat, when I type a value in the field named “Text2”, the barcode gets updated:

I was quite pleased, assuming that things would be the same in Reader. This is just another field isn’t it? But then I tried it, and…

Googling suggested that the document actually needs to be reader-enabled. So I went back to Acrobat X and chose Save As -> Reader Extended PDF -> Enable Additional Features. Again, we get a dialog box:

Hmmm, it does not say anything about Barcodes. And indeed: after enabling Reader still does not update the barcodes. What now?

Maybe it was not such a good idea to ignore the Barcoded Paper Forms Solution message after all. I opened Acrobat help, and entered “barcode paper forms solution”. The first hit on the “Community Help” page, was “Adobe LiveCycle ES2 * Using paper forms barcodes”. This lead to some general story about using paper forms barcodes. No prices, no product info, and certainly no howto. Well, I found a nice picture…

And, at the end, there is the note “To make use of the paper forms barcode, your organization must have implemented LiveCycle Barcoded Forms”. Of course no link, just yet another term.

At this point I felt very reluctant to start searching again. Apparently all this was related to LiceCycle Designer. Notice that the article says AdobeLiveCycle Designer ES2. I have that as part of Acrobat Pro, so I started it up, opened the PDF and let it convert the document. Then it said this.

Fair enough, even though Acrobat apparently had no problems with this. So, I dragged the Barcode field a bit bigger:

My Script? What script? I enabled the script editor and saw that there was some javascript associated with the “calculate” event. Well, commented-out code actually:

Right, so now I am supposed to rewrite this into some FormCalc expression? I think not!

Back to square one. We create an empty form in LiveCycle designer, and we choose Insert – Barcodes – QRCode from the menu:

And as an award, we now have a read-only QR code on our form. There is nothing much we can do with that, except assigning some fixed value to it.

Luckily the dialog box mentioned a “Paper Forms Barcode”. So we look in the menu again. Yes, there they are: Insert – Barcodes – Paper Forms Barcodes. Again a tip (isn’t this great?)

Of course I am going to ignore the talk about separate licenses. we get:

I create a new text box, as well as a new collection, and I add the text box to it. I leave this as an exercise to the reader… You will probably get warnings about exceeding the barcode capacity. Just specify a maximum numbers of characters for the text field.

And again, this is not going to work out-of-the-box for Adobe Reader. At least the effect is consistent:

In LiveCycle designer, we choose File – Distribute Form... We choose “Manually collect responses in my email inbox”.

On the next screen, we choose the second option (save a local copy). Then we specify an email address, and finish the wizard. We now have a “distributed” variant of our form. It should have been enabled, I think.

And then….

I now read somewhere on the web that I actually need LiveCycle RE (reader extensions) to enable dynamic barcodes in reader! I give up. Sigh. Why is it that Adobe treats barcodes so much different from other form fields? And why does this picture above even mention LiveCycle ES2?

BitmapEncoder.Save puzzling behavior

noreply@blogger.com (TallComponents) — Mon, 20 Jun 2011 10:33:00 +0000

In our effort to release editions of our software that have no reference to the System.Drawing assembly, we are porting GDI+ code to WPF. While doing this, we encounter some puzzling behavior from System.Windows.Media.Imaging.BitmapEncoder.Save.

We call BitmapEncoder.Save and pass it our own implementation of System.IO.Stream as follows:

using System.Windows.Media.Imaging;

BitmapFrame frame = BitmapFrame.Create(bitmapSource);
BitmapEncoder encoder = new BmpBitmapEncoder();
encoder.Frames.Add(frame);
encoder.Save( myStream );

The object myStream is a derived stream which implements some overloads available in System.IO.Stream. We would expect that the Save method calls the Stream.Write method only and does not call Stream.Read. Our initial implementation of Stream.CanSeek and Stream.CanRead returns false and Stream.Read throws NotSupportedException as specified in the MSDN documentation.

To our surprise, it turned out that the framework calls the Read method even though CanRead returns false!

After some experimentation, we discovered that when CanSeek returns true, the framework does not call Read. But, even more surprisingly it never calls Seek.

To summarize:

CanSeek	false	true
CanRead	false	false
CanWrite	true	true
Save calls Seek	No	No
Save calls Read	Yes	No

In other words, making the stream seekable, causes the framework to suddenly not call Read anymore, even though Seek is never called. This totally puzzles us.

Any insightful comments are welcome!

Architecture of an HTML Consumer

noreply@blogger.com (TallComponents) — Mon, 06 Jun 2011 12:26:00 +0000

In this post I will roughly outline the architecture of our HTML to PDF converter. I believe it applies largely to any HTML consumer.

STEP 1: Tidy

The first step is to tidy the HTML. Most HTML documents are not well formed. Meaning that they are not XML documents. By first converting the HTML document into an equivalent XML document, we create the required conditions for the subsequent transformations. Typical tidy transformations include the following:

Before	After
<h1>heading <h2>subheading</h3>	<h1>heading</h1> <h2>subheading</h2>
Before	After
<i><h1>heading</h1></i> <p>new paragraph <b>bold text <p>some more bold text	<h1><i>heading</i></h1> <p>new paragraph <b>bold text</b> <p><b>some more bold text</b>
Before	After
<body> <li>1st list item <li>2nd list item	<body> <ul> <li>1st list item</li> <li>2nd list item</li> </ul>

STEP 2: Execute JavaScript

This step is far from trivial because it involves executing JavaScript. So one actually needs to build a JavaScript interpreter (or use an existing one). When we started working on our HTML converter, we already had our own JavaScript interpreter. But it was conditioned for JavaScript code that one typically finds in PDF documents. This type of JavaScript tends to be far less complex than the JavaScript in current HTML documents. We rarely receive a bug report related to JavaScript embedded in PDF documents. But when we started using the same interpreter with real-life HTML documents, it turned out to be flawed and having many deficiencies. Especially supporting the jQuery library turned out to be an enormous task. jQuery makes extensive use of more advanced JavaScript features such as prototypes and closures.

Here is a typical conversion that takes place when executing JavaScript:

Before	After
<html> <head> <script type="text/javascript"> function load() { var x = document.getElementById("foo") x.innerHTML = "Hello TallComponents!"; } </script> </head> <body onload="load()"> <h1 id="foo">Hello World!</h1> </body> </html>	<html> <body> <h1>Hello TallComponents!</h1> </body> </html>

STEP 3: Resolving CSS

Cascading style sheets are used to separate content from presentation. CSS is resolved after JavaScript has been executed because JavaScript may also manipulate CSS. CSS can be specified in three ways:

External stylesheet. These are specified using the LINK element as follows:
```
<HEAD>
<LINK href="special.css" rel="stylesheet" type="text/css">
</HEAD>
```

Inline stylesheet. These are speficied using the STYLE element as follows:

<HEAD>
<STYLE type="text/css">
H1 {border-width: 1; border: solid; text-align: center}
</STYLE>
</HEAD>

Inline style. Here is a typical example:

<P style="font-size: 12pt; color: fuchsia">
Aren't style sheets wonderful?
</P>

The CSS resolver transforms the HTML document such that it only has inline styles while being equivalent to the original document.

STEP 4: LAYOUT

Now that the HTML document has been normalized with respect to syntax and CSS and initialization JavaScript code has been executed and removed, all visual elements have to be placed and formatted. This is referred to as the layout step.

Although we convert to PDF, our layout module has been designed such that by implementing a specific interface we may just as well convert to SVG or GDI+.

Remark

While the above four steps have been presented as sequential steps, in reality they are performed more or less in parallel for performance reasons.

Two wrongs don’t make a right. Two negatives do make a positive

noreply@blogger.com (TallComponents) — Mon, 30 May 2011 13:50:00 +0000

We encountered a PDF document from a customer where we failed to geometrically sort the glyphs correctly. Glyphs appearing lower on the page were returned earlier in the sort order by the text extractor.

It turned out that not only the font size, but also the horizontal scaling and finally the CTM (current transformation matrix) scaled the text negatively in both direction two times. The net result is positive of course. Our software should have handled all these scales using a generic algorithm but we dropped one: we took the absolute value of the horizontal scale (Tz operator).

Here is a screenshot from our internal PDF nitpicker PDFSpy:

Operation 2 sets the vertical scale to –1. Operation 9 sets the font size to –5 (this is basically a negative scale in the horizontal and a negative scale in the vertical direction). Operation 11 sets the horizontal scale to –1 (the operand of the Tz operator must be divided by 100). When we take all this into account the scale in both directions is positive.

We fixed this in maintenance update 3.0.63.0 of PDFKit.NET 3.0.

Testing our HTML to PDF Converter

noreply@blogger.com (TallComponents) — Thu, 26 May 2011 10:12:00 +0000

Among other tests, we use the W3C CSS 2.1 test suite to assure the quality of our HTML to PDF converter WebToPDF.NET.

W3C Test Suite

The test suite is published as a set of documents (.xht files) without a folder structure. The first thing we did was organize these files into folders that correspond to the different chapters of the CSS 2.1 specification. We wrote a little tool that generates this folder structure based on the chapter information that is stored in the metadata of each test document. This structure makes testing easier. E.g. if we change some code related to chapter 5, we first run these tests and once these are fine, we run the rest.

Converting all HTML documents to PDF

We use an internal command line tool that enumerates all the test documents and converts each .xht to PDF. If an exception occurs, we flag this test as ERROR. If no exception occurs, the PDF is stored in a temporary output folder. We then compare this PDF with a reference PDF document (this is what we expect the PDF to look like). This reference PDF document was created the first time that a converted PDF was manually approved. If a reference does not exist yet, the test is flagged as NO-REF. If the reference exists but the output differs, then the test is flagged as FAILED. Otherwise, it is flagged as PASSED. Obviously, the ultimate goal is to have all tests flagged as PASSED.

The first time we ran the tests, each test was flagged either as ERROR (an exception occurred) or as NO-REF (because no output was approved yet). We first fixed our code so that no exceptions were thrown.

Inspecting the Test Results

Next, we have to visually inspect each output document and decide whether the output is correct or not. For this we compare the output with how a ‘trusted’ browser renders the HTML. Because this involves inspecting A LOT of output documents we wrote a tool that makes our life a bit easier. This tool evolved during the testing phase in order to maximize productivity. Here is how it looks:

Without explaining every detail of this tool, let me go over the most-used features. What you see in the above picture is how our converter renders attribute-003.xht (in Chapter 5 of the W3C test suite) to PDF. This test is self-explaining. Obviously, each line has the color that it should have.

The button F9 lanuches a browser (we can select from all major browsers) so we can compare our output with that of a major browser such as Chrome. F11 (Next) jumps to the next test. F12 (Make Reference) copies the output to the reference folder, basically approving the output.

Reporting

Per chapter we generate a test report that gives a quick overview of the results as follows:

For the complete test set we generate a test report like this one:

As always, comments are welcome!

If you can build an XBox, you can build a Blender!

noreply@blogger.com (TallComponents) — Tue, 24 May 2011 10:26:00 +0000

Our PDF rasterizer engine uses GDI+ for rendering. In this way rendering to a printer is no different than rendering to the screen, and we do not have to bother with low level concepts like resolutions. In any case, we really do not like the idea of sending bitmaps to our high resolution color printer. It is 2011 you know.

Along the way however, we discovered that GDI+ does not quite cut it. It has all sorts of quirks and limitations, and it lacks some features that PDF has. So, we spent some of our time inventing GDI+ workarounds.

One area that has been particularly painful is the complete lack of blend modes in GDI+. Up to a point we have been able to approximate the blend modes using normal transparency. This works surprisingly well for many files. There are however some effects that no form of ordinary transparency will ever be able to approximate.

In GDI+, the only real solution for this appears to be to render both the foreground and the background as a bitmap and do the blending ourselves, pixel for pixel. So why have we not done this already? The problem is not so much the blending operations. These are trivial. The problem is: keeping (printing) quality without generating huge bitmaps that slow down printing to a crawl. So here we are: we have PCL6 and PostScript 3, and the only way to get these pages on our high resolution color printer is basically by avoiding these high level printer languages entirely…. Pfff.

So, we started telling ourselves: GDI+ is old. Microsoft is bound to come up with an improved, modern successor. We decided to wait a bit, hoping to avoid complaints. And then WPF arrived at the end of 2006. Hurray!

Wait… no Blend modes yet, despite a product called Expression Blend. We waited a bit more.

I have been told that blend modes are difficult to implement in WPF because of the retained graphical system that WPF employs. I find that hard to believe. If that were true WPF would basically be broken. And supporting blend modes is no more difficult than supporting transparency. The pixels just need to be combined with their backdrop in a slightly different manner. WPF has plenty support for ordinary transparency. As I see it, this would be a tiny technical step for Microsoft.

In the meantime, Microsoft has started telling us not to rely on GDI+ anymore for ASP.NET services and it is ‘gently’ pushing us towards WPF. See http://msdn.microsoft.com/en-us/library/system.drawing.aspx.

It is now halfway 2011 and WPF still has no Blend Mode support. How is this system (and XPS) ever going to be a serious competitor of PDF in terms of high-end graphical rendering? I understand that 3D rendering is also important, but seriously Microsoft: the last time I looked at your gaming platform – albeit increasingly popular – it was not more profitable than your office division.

So come on Microsoft, if you can make an XBox, you can also build a Blender!