Ben Langhinrichs

Photograph of Ben Langhinrichs

E-mail address - Ben Langhinrichs






September, 2019
SMTWTFS
01 02 03 04 05 06 07
08 09 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30

Search the weblog





























Genii Weblog


Civility in critiquing the ideas of others is no vice. Rudeness in defending your own ideas is no virtue.


Mon 16 Sep 2019, 03:22 PM
As folks like Mat Newman run around the globe signing up some new Notes/Domino customers and reinstating others, there is a recognition that Notes/Domino still has a lot to offer. While the promise of new features may encourage some, many simply want the same stability, reliability, and ease-of-development that we have all known for years (er, decades).
 
But while consistency is good in some areas, there are other areas that are consistent in unfortunate ways. One of those is mail rendering. Too often, people send off emails not realizing that they will arrive looking far different and sometimes containing less information that intended.
 
Here's an example from Singapore (okay, the original customer was from that region, but the identifying information has been altered). This was a real problem for a customer, which you could blame on the cringeworthy decision to use gradients except that many more people do than you might hope.
 
 
In Notes V11 Beta 1 (though it looks identical in earlier versions because rich text is nice like that):
 
 
Inline JPEG image
 
Sent to Gmail using the Notes 11 client (set to send as MIME):
 
Inline JPEG image
 
 
Sent to Gmail using the Notes 11 client (using CoexLinks Fidelity):
 
Inline JPEG image
 
 
Let me assure you, this is not a Notes 11 Beta problem, or at least no more than previous versions. I went back and testing to ND7...
 
Inline JPEG image
 
 
Amazing consistency. I checked these versions with CoexLinks Fidelity as well.
 
Inline JPEG image
 
 
I guess the message is, there are tons of great reasons to use Notes/Domino even in 2019, but don't expect everything to have improved. For that, you might need to call an ISV and make the great in Domino even greater.
 
 
 
Additional note:
In case you happen to know (someone always seems to) that Outlook 365 does not support gradients, this is how the CoexLinks Fidelity email looks in Outlook 365. Note that we degrade to the higher contrast color so that you will not miss any information.
 
Inline JPEG image
 

Copyright © 2019 Genii Software Ltd.

Tags:

Mon 9 Sep 2019, 10:21 AM
Last week, I started a series about certain constraints on exporting or archiving Notes data to PDF. There has been a lot of chatter recently about exporting to PDF, a feature that may be supported natively in HCL Notes V11, and that is offered as an archiving solution by some consultants and vendors. 
 
The PDF format itself is great for certain use cases, but has certain limitations by its very nature, and other limitations due to expectations. As I said in my first post, PDF is seen as being a little like an image. This is wrong on two counts. The first is that the data is not pixel perfect by any means. The second is that in to the extent that it shows what is visible, an image does a lousy job of revealing what is not visible. In this example, I actually show three different instances of where data is lost or obscured in different ways. The first part has the missing data. With caption tables, the caption (or title) is missing, thus losing context. With sections that have not been expanded, the title is there but the contents are missing. And of course, all the attachments and doclinks are non-functional in any case. The second example has obscured data. With a numbered list in a table (not tweaked in any way to try to get this result), part of the numbers is missing. Please note, there examples are only representative of other missing or obscured data with PDF rendering.
 
This is the fourth of ten primary issues. Depending on what vendor or driver you use, a few of these may have at least a partial solution, but they are good items to check when validating your approach. The table of contents of all ten issues will be at the bottom of this post.
 
 
4a) Missing data
 
Portion of a rich text field with a caption table and a section.
 
Inline JPEG image
 
 
PDF rendering. Note that the caption titles are missing, and the section title is all that remains.
 
Inline JPEG image
 
 
Rendered by the Midas LSX to HTML. The first image shows as it opens, while in the second I have clicked on the Q3 caption and section title to show them open.
 
Inline JPEG image
 
 
After clicking the Q3 caption and section title (both are clickable with our HTML rendering).
 
Inline JPEG image
 
 
4b) Obscured data
 
Portion of a rich text field with a numbered list inside a table (same wide table as before, though I don't show as much).
 
Inline JPEG image
 
 
PDF rendering. Note that the second page looks like it starts a new numbered list, but is really number 11. I also noted the left data cut off as shown in previous post.
 
Inline JPEG image
 
 
Rendered by the Midas LSX to HTML. 
 
Inline JPEG image
 
 
Table of Contents (will be updated as the blog series continues)
 
Want to try out our Midas LSX export for yourself? Simply fill out the online evaluation request, and we'll get you started. There's no cost to seeing it for yourself.
 

Copyright © 2019 Genii Software Ltd.

Tags:

Fri 6 Sep 2019, 11:53 AM
A couple of days ago, I started a series about certain constraints on exporting or archiving Notes data to PDF. There has been more chatter recently about exporting to PDF, a feature that may be supported natively in HCL Notes V11, and that is offered as an archiving solution by some consultants and vendors. 
 
The PDF format itself is great for certain use cases, but has certain limitations by its very nature. One of those is that It is page based, and pages are defined with set heights and widths that don't easily accommodate the different screen sizes and orientations of the modern world. Worse, pages have to cut off sometimes, which means large amounts of data may be lost completely.
 
This is the third of ten primary issues. Depending on what vendor or driver you use, a few of these may have at least a partial solution, but they are good items to check when validating your approach. The table of contents of all ten issues will be at the bottom of this post.
 
 
 
3) Wide tables or table cells may be cut off and all data to the right lost
 
Original Notes rich text field. This is based on a customer I am working with right now, but wide tables are quite frequent in large complex forms. This table is so wide, I had to take two screen shots, but in Notes, I could simply scroll horizontally to see it all.
 
Inline JPEG image
 
Inline JPEG image
 
 
PDF rendering. There is no horizontal scroll bar, and the data to the left of the page is simply cut off
 
Inline JPEG image
 
 
Rendered by the Midas LSX to HTML. The text flows down in the table because of how the margin was set. If it were set differently in Notes, this would render with a horizontal scroll bar. Either way, all data is preserved.
 
Inline JPEG image
 
If we view the same HTML file with a different screen size, it still flows and is readable on screen.
 
Inline JPEG image
 
 
Table of Contents (will be updated as the blog series continues)
 
Want to try out our Midas LSX export for yourself? Simply fill out the online evaluation request, and we'll get you started. There's no cost to seeing it for yourself.
 

Copyright © 2019 Genii Software Ltd.

Tags:

Thu 5 Sep 2019, 10:25 AM
Yesterday, I started a series about certain constraints on exporting or archiving Notes data to PDF. There has been more chatter recently about exporting to PDF, a feature that may be supported natively in HCL Notes V11, and that is offered as an archiving solution by some consultants and vendors. 
 
To reiterate, the PDF format itself is great for certain use cases, but has certain limitations by its nature. It is page based unlike both Notes and the web, and it is more of an image of a document than the document itself. That played a role in the first post which showed how attachments appear to be there in the PDF, but are not clickable or launchable, and require a separate process to save at all. Today's peril is similar with a Notes feature that is widely depended upon, the doclink.
 
This is the second of ten primary issues. Depending on what vendor or driver you use, a few of these may have at least a partial solution, but they are good items to check when validating your approach. The table of contents of all ten issues will be at the bottom of this post.
 
 
 
2) Doclinks not clickable at all, or go to the original source
 
Original Notes rich text field. A table of doclinks (from 2008 BP forum) showing original hierarchy in view.
 
Inline JPEG image
 
and if we follow one of the links, we get to
 
Inline JPEG image
 
 
PDF rendering. The doclinks look like they are there, but you can't follow them, making them both useless and frustrating
 
Inline JPEG image
 
 
Rendered by the Midas LSX to HTML. You can seem them, you can click them, you can configure where they'll be resolved (in this case, to other local HTML files)
 
Inline JPEG image
 
and if we follow one of the links, we get to
 
Inline JPEG image
 
 
Table of Contents (will be updated as the blog series continues)
 
Want to try out our Midas LSX export for yourself? Simply fill out the online evaluation request, and we'll get you started. There's no cost to seeing it for yourself.
 

Copyright © 2019 Genii Software Ltd.

Tags:

Wed 4 Sep 2019, 09:18 AM
Recently, there has been an increased interest in exporting to PDF, a feature that is promised natively for Notes Version 11. There are also migration "solutions" that include this feature. At Genii Software, we have considered adding this as a feature, but while it is not technically difficult, we are all too aware of the traps that PDF archives face. 
 
The PDF format itself is great for certain use cases. It also has certain limitations by its very nature. It is page based, reflecting its origin back when its primary use was presenting page based content either from scanned pages or word processors that were also page based. But neither Notes or the web are inherently page based, so PDF's have to "break things where they oughtn't be broke". In addition, a PDF is largely, though not exactly, a snapshot or image of the contents. But just as an image of your dinner posted on Instagram is little help when you are hungry, an image of your Notes document is fairly limited compared to the active Notes document itself.
 
We have identified ten primary issues to be aware of when exporting/migrating to PDF, though there may be more. For the purposes of this blog series, I'll compare PDFs to how we export/migrate to HTML or MIME. The first five are issues with any rich text exported to PDF (in case you simply export the rich text field), while the second group of five are with documents rendered with their form exported to PDF, usually the case. Depending on what vendor or driver you use, a few of these may have at least a partial solution, but they are good items to check when validating your approach.
 
 
1) Attachments not launchable, may or may not even be saved, and are difficult to associate by name alone
 
Original Notes rich text field. The second attachment was clicked, opening this familiar dialog box..
 
Inline JPEG image
 
 
PDF rendering. Looks nice. Attachments not launchable. Even if attachments saved separately, what names are used since they can't all be Sales.xls?
 
Inline JPEG image
 
 
Rendered by the Midas LSX to HTML. Also looks nice. The second attachment was clicked, opening this matching dialog box.
 
Inline JPEG image
 
 
Table of Contents (will be updated as the blog series continues)
 
Want to try out our Midas LSX export for yourself? Simply fill out the online evaluation request, and we'll get you started. There's no cost to seeing it for yourself.
 

Copyright © 2019 Genii Software Ltd.

Tags:

Fri 16 Aug 2019, 09:50 AM
Fifteen years ago, I started a campaign to convince IBM to at least fix the very easiest of rendering issues, the point size of text. I wrote about it on forums and brought it up with IBMers, but nobody seemed to care. It was part of my motivation for writing CoexEdit, which is now AppsFidelity. A memorable post from early 2005 is Selling a 9 year old on CoexEdit, and when CoexEdit was a Beacon Award finalist in January 2006, I thought maybe the point had been made.
 
Well, not quite. Not only was the point problem not fixed in version 9.0.1 or its many fixpacks, but it remained inconsistent. A couple examples. Pay attention to where the small sizes change.
 
Notes/Domino 9.0.1 MIME rendering (sending as email whether rendered by client or server)
Inline GIF image
 
Domino 9.0.1 HTTP rendering (viewing on web page)
Inline GIF image
 
There are other renderings as well, such as when the form saves the rich text field as MIME, when Domino Access Services renders the document to MIME. Sometime 9pt is <font size=1> and sometimes it is <font size=2>. While 10pt and 11pt appear about the same in all, sometimes the size is explicit, as in this from the rich text saved as MIME:
 
<font size=1 face="Times New Roman">Text in 6 pt</font>
<br><font size=1 face="Times New Roman">Text in 7 pt</font>
<br><font size=1 face="Times New Roman">Text in 8 pt</font>
<br><font size=1 face="Times New Roman">Text in 9 pt</font>
<br><font size=2 face="Times New Roman">Text in 10 pt</font>
<br><font size=2 face="Times New Roman">Text in 11 pt</font>
<br><font size=3 face="Times New Roman">Text in 12 pt</font>
<br><font size=3 face="Times New Roman">Text in 13 pt</font>
<br><font size=4 face="Times New Roman">Text in 14 pt</font>
<br><font size=4 face="Times New Roman">Text in 15 pt</font>
<br><font size=4 face="Times New Roman">Text in 16 pt</font>
<br><font size=4 face="Times New Roman">Text in 17 pt</font>
<br><font size=5 face="Times New Roman">Text in 18 pt</font>
<br><font size=5 face="Times New Roman">Text in 19 pt</font>
<br><font size=5 face="Times New Roman">Text in 20 pt</font>
 
and other times it is implicit such as this from the Domino HTTP:
 
<font size="1" face="Times New Roman">Text in 6 pt</font><br>
<font size="1" face="Times New Roman">Text in 7 pt</font><br>
<font size="2" face="Times New Roman">Text in 8 pt</font><br>
<font size="2" face="Times New Roman">Text in 9 pt</font><br>
<font face="Times New Roman">Text in 10 pt</font><br>
<font face="Times New Roman">Text in 11 pt</font><br>
<font size="4" face="Times New Roman">Text in 12 pt</font><br>
<font size="4" face="Times New Roman">Text in 13 pt</font><br>
<font size="5" face="Times New Roman">Text in 14 pt</font><br>
<font size="5" face="Times New Roman">Text in 15 pt</font><br>
<font size="5" face="Times New Roman">Text in 16 pt</font><br>
<font size="5" face="Times New Roman">Text in 17 pt</font><br>
<font size="6" face="Times New Roman">Text in 18 pt</font><br>
<font size="6" face="Times New Roman">Text in 19 pt</font><br>
<font size="6" face="Times New Roman">Text in 20 pt</font><br>
 
While that seems an innocent difference, remember that CSS will override a missing size differently than an explicit size, so you can have a magnified text page where the 10pt and 11pt are larger than the 14pt, 15pt, 16pt, and 17pt.
 
All of these issues ignore the extremely easy to implement CSS style that will use point sizes, as our products have done since late 2004.
 
But while IBM did not pay attention, HCL is aware of the issue and making some progress. If you look at the Notes client MIME rendering (email sent when location document specifies sending MIME), you will see:
 
Notes 10.0.1 MIME rendering (sending as email rendered by client)
Inline GIF image
 
Finally, CSS styling to get exact point sizes! This is implemented as well in places where the form saves the rich text field as MIME. It is not fixed when the Domino server renders the MIME, as in:
 
Domino 10.0.1 MIME rendering (sending as email rendered by server)
Inline GIF image
 
It is also not fixed in Domino 10.0.1 HTTP or Domino Access Services:
 
Domino 10.0.1 HTTP rendering (viewing on web page)
Inline GIF image
 
But HCL gets that this is an issue. They mentioned fixing rich text as a major bullet item in their AppDev roadmap at the Factory Tour, and this is one of many fixes necessary and (as far as I can tell) planned.
 
The point is consistency, accuracy, and fidelity. HCL gets it. Hopefully, soon we will all get there.
 

Copyright © 2019 Genii Software Ltd.

Tags: