Making PDF.js work with digital signatures

Out of the box PDF.js doesn’t support displaying signatures on PDF files. This is strange since it’s such a common scenario and it’s been requested many times over the years.

Thankfully there’s a simple solution to this. You need to modify the pdf.worker.js file with the following modification.

In the var WidgetAnnotation = /*#__PURE__*/ function, look for the following code:

if (data.fieldType === 'Sig') {
  data.fieldValue = null;

And comment out the setFlags line like this:

if (data.fieldType === 'Sig') {
  data.fieldValue = null;
  // _this3.setFlags(_util.AnnotationFlag.HIDDEN);

You don’t need to make any modifications to the pdf.js file itself just the pdf.worker.js file.

To do this you download PDF.js from the project page. Take the pdf.worker.js file from the build folder and make the modification. In your web project, use the local modified version of this file but keep referencing the base file through a CDN (or locally if you wish).

Don’t forget to minify your modified worker file afterwards.

Of course, you’ll have to make this manual modification each time you update PDF.js.

Final Fantasy like screen transition effect


I’ve created a small project where I tried to produce an effect similar to the Final Fantasy 8 screen transition effect.

You can see a video of the original effect here and my project in action here.

The code is accessible through the GitHub repository.

Whilst I’m a Firefox user first I had to resort to refreshing the page on Firefox as it leaked memory of the amount required for the canvas’ image data. This leak wasn’t present on Chrome, Edge or Safari.

I’m writing directly to the image data like a buffer which I found out is far from optimal. It’s far better to only stick to drawing primitives from the API but this ultimately limits what you can do which is why I stuck with the manual operation on the image data.

Using a type alias to create a new name for a preexisting type like Document

I often need to work with auto-generated types that have been generated by Swagger based on an API definition.

These types sometimes clash with the names of preexisting types. For example the Document object, which normally refers to: Any web page loaded in the browser and serves as an entry point into the web page’s content, but in my case is also the name of an interface generated by Swagger.

Since you don’t need to import the Document type to use it in TypeScript / Angular projects, every time I try to use the generated Document class it’s referring to the DOM’s Document by default.

This can be fixed by adding an import statement, but to avoid dealing with this project-wide we can use type aliases which let us give a type a new name:

type MyAppDocument = Document;

Since I can’t change the generated Document file itself, it would get overwritten the next time it’s generated, I create a type-alias.ts file like this:

import { Document } from './document';

export type MyAppDocument = Document;

Which then allows me to use the new MyAppDocument type everywhere.

Minimize the amount of changes in a changeset

When creating a new change set, always try to minimize the amount of changes it introduces.

Do this by only modifying what needs to be modified to implement a feature or fix a bug. Keep formatting and refactoring changes for another commit.

The story of how I came to this practice

Many years ago I read Clean Code. One of the things it discussed was to check in our code a little cleaner than when we checked it out. This meshed with the idea of continual improvement through refactoring which I was already following.

I took this principle to heart and made formatting changes, introduced constants, removed commented code and made small refactorings with my change sets. I kept big refactorings for different commits… well most of the time anyways…

Then later on an open source project I contributed to, I was asked during code reviews to keep those changes out of the change sets. I was surprised since I thought I was helping improve the code’s quality. The project’s maintainers reasoning was that the change set needed to include only the changes required to correct the bug that was addressed or implement the new feature we were working on. Refactorings should be kept as different endeavors or for instances where a piece of code was being completely rewritten during the course of normal work.

Over time I started to see this made more sense than my previous practice and eventually started following this practice as well.

One thing I like to do now is keep notes of what changes I want to make, complete my current work and then make a separate commit for formatting and refactoring changes. If I don’t take notes, too often I forget all the little changes I wanted to do and never get around to doing them.

The why

When a commit needs to be read later on to understand the changes, revert them or when doing a blame/annotate to find out why a change was made it’s much easier if all the changes are related to the commit message and associated ticket number.  Otherwise you need to reason for each modification if it was done in relation to the commit’s purpose or as a “bonus” refactoring.

Also, including unnecessary changes makes for longer commits which make for longer code reviews. In my experience the longer the review, the more chances some stuff will get glanced over.

Finally, every change we make, even when having a robust test suite risks introducing regressions. If you later find out your latest changes introduced a bug and it turns out it was in a refactoring, it’s much easier to revert or correct this refactoring without needing to revert a bug fix or feature at the same time.