2 Javascript discoveries

If you are an experienced Javascript developer, the following will not come as a surprise to you, but for those who might be struggling with some of the quirks of this otherwise pretty useful language, I’d like to share 2 discoveries. I spent quite some time trying to understand why certain code wouldn’t do what I intended and after several frustrating hours, I finally found that

  • Javascript is not a pure “pass-by-value” language, as I thought. When passing an object to a function, any changes to the internals of that object within the function, will alter the object outside the function.
  • A long-running JavaScript will freeze the browser, preventing it from being updated, so any visual changes will not be visible, until after the processing has finished.
    • Solution: Add a delay (even a 0ms delay) between making a visible change, and starting the script. Add this delay using setTimeout():


  • Some complex code on one of my websites didn’t behave properly, even though the code looked fine. Eventually I learned that an object that I passed to a function should not be altered within that function, as it directly changes the object itself, rather than a copy, which would be the case in a pure “pass-by-value” language. See http://nsono.net/javascript-pass-by-value-or-pass-by-reference/ for details.
  • I’m using the powerful datatables plugin on my websites. As some tables contain a lot of columns, I wanted to provide shortcuts to dynamically show or hide certain columns. You can do that with the column().visible() method, but as the table is large, it takes a few seconds to see the result. I therefore wanted to show the user that some processing was going on, with a small popup or by adding a “changing” class to a DOM element. However, these visual changes did not show, or better, they only showed AFTER the processing was done. I really didn’t understand why it was not working, until eventually http://stackoverflow.com/questions/20048357/loading-overlay-with-datatables gave a clue: “A long-running JavaScript will freeze the browser, preventing it from being updated.” Using setTimeout() with a delay of 0ms finally solved it.

Using epilogue.ps to set default Inital View settings in PDFs created with Adobe printer / Distiller

I’m using the Adobe printer or Distiller to create PDF documents. While you can set most PDF settings in the .joboptions file, there are a few things that I want that are not available:

  • I like the Initial View of the PDF to be
    • Page layout: Single Page
    • Magnification: Fit Page

To do that, I need to go open every PDF in Adobe Acrobat, and select File > Properties to change it. A very time-consuming, cumbersome task if you need to do that for a lot of files.
After a lot of googl’ing and trial-and-error, I finally managed to automate this by using pdfmark additions. pdfmarks are extensions to Postscript. These can be added to PDFs by adding them to the epilogue.ps file in %USERPROFILE%\AppData\Roaming\Adobe\Adobe PDF\Distiller\Data and then creating a custom joboptions file that uses the updated epilogue.ps file (the default settings will not use the epilogue.ps file).


  1. Open %USERPROFILE%\AppData\Roaming\Adobe\Adobe PDF\Distiller\Data\epilogue.ps in a text editor
  2. After the line “‘% Insert your custom PostScript here”, add
  3. Save the epilogue.ps file
  4. Launch Distiller, select a joboption you want to use
  5. In Distiller, select Settings > Edit Adobe PDF Settings…
  6. Select Advanced, check “Use Prologue.ps and Epilogue.ps” option:
  7. Save As… to save the edited job option as a new one.
  8. In Windows, go to the Devices and Printers View, right-click the Adobe PDF printer and select Printer properties.
  9. Click Preferences… and select the .joboptions file as Default Settings:
  10. (Optional) Uncheck Delete log files for successful jobs if you want to look at the log file. It took me a while to find it, but on my Windows 10 machine, it was located at %USERPROFILE%\AppData\Local\Adobe\Acrobat\Distiller 2015\messages.log

I found the initial information about pdfmark in this blog post. The link to the pdfmark Reference document no longer works, but you can find the pdfmark Reference on the Adobe Devnet site.


Using JSConsole to debug an javascript issue on an iPad

Yesterday I ran into an issue with one of the websites I’m developing. All of a sudden, some pages would not show correctly on an iPad. However, as Safari on the iPad doesn’t provide “developer tools”, it was nearly impossible to determine what went wrong. The pages were working fine on other devices, including a normal laptop and an Android phone. Also Chrome’s emulation mode did not show any problems.

Digging into the Settings on the iPad, I found the “Web Inspector” option in the Advanced Settings tab for Safari. It states “To use the Web Inspector, connect to Safari on your computer using a cable and access your iPad from the Develop menu.” That’s fine if you have a Mac computer, but I only have Windows PC’s…

Luckily, after some Googling, this website from Leon Atherton came to the rescue. While it covers Remote Debugging on OS X, it also provides information about a cool web app called JSConsole. You simply need to add a script tag into your web page and that will capture any console.log input.


Pretty neat.

PS. The issue was linked to the use of arrow functions in one of my javascript pages. Those are not supported in Safari. And not in IE either, apparently. Which is a pity as they made a piece of code where I used the every() method a bit more compact. So I instead of

I now have to use:

Oh well…