HCL Domino Ideas Portal
Welcome to the #dominoforever Product Ideas Forum! The place where you can submit product ideas and enhancement request. We encourage you to participate by voting on, commenting on, and creating new ideas. All new ideas will be evaluated by HCL Product Management & Engineering teams, and the next steps will be communicated. While not all submitted ideas will be executed upon, community feedback will play a key role in influencing which ideas are and when they will be implemented.
For more information and upcoming events around #dominoforever, please visit our Destination Domino Page
The "convertToHTML" method of the "NotesRichTextItem" class (LotusScript and Java) is not supported from V11.0.1.
Therefore, it is not supported in latest release Notes/Domino 12.0.2 either.
For more information, see the information at the link below.
HCL Notes, Domino, and Designer 11 documentation updates
If you use 'convertToHTML' in your current application, it may work in Notes/Domino 12.0.2, but if something goes wrong, HCL will not be able to provide support to you.
You need to consider modifying your application in such scenario.
You can use the LotusScript method "NotesMIMEEntity" to convert the value present in the Rich Text field to HTML.
Domino does support HTML, in that you can create MIME "newsletters" forms/pages, and then the Notes client will display that HTML in a MIME container just fine. The only thing, is we create those pretty MIME emails in one Notes app, that basically a Newsletter blast, and then folks in Notes, or xMail see the MIME email as a HTML email. It works great overall.
However, with a product that is a bit of a can-do-anything kind of app server and collection of apps, it has a tendency to release a pretty cool new feature, languish the feature while other interests abound, and then go back and either release it as an updated feature, or abandon it for a new way later on.
All we really need is for the Notes client two toggle to compose email in MIME and allow the "block" creation, in an easy way of the standard HTML components. And yes, it was great to get the DIV, and it made sense to deliver the DIV as a layer in R5 or R6, when it came out, but we don't really use a DIV the way it was originally intended. The basic 2012, 2013, and 2017 WordPress "blocks" show a good progression of HTML blocks being updated.
Similar idea: https://domino.ideas.aha.io/ideas/NTS-I-101
RichText is certainly no worse than other formats. On the contrary - it can even be called simple. See what's going inside the *.doc-format - it's just awful! There is a whole file system! But people somehow write the code and convenient API, and work in Word without problems.
The Notes client's problem is not in RichText, but in the fact that the RichText content rendering engine to a visible form and back has not been updated, since the days of Netscape 6 (or something like that). That is, in essence, every form opened to the user, is a page displays via prehistoric browser which embedded in the Client. From here all birth injuries Notes: prehistoric CSS support, the need to reopen the document to update RichText, etc.
And it was not updated because the direction was chosen - go to a thin client. If the rendering engine in the client were kept up to date, then no one would have thought of switching to a thin client! See what great controls on the sites now have to build tables - very convenient and fast! And all this can be obtained in the client, if to update the engine to the current state.
When opening a document, work in a modern browser page, and when necessary, convert its contents to RichText and back. This is the usual simple XSLT that you need to do when NotesUIDocument.Save (but only when RichText was changed) and with NotesUIDocument.Refresh(True) and NotesRichtextItem.Update, without any reopened. It is necessary for each field in the document and the document itself to set Changed = True property on any change of the field. Naturally, Computed Fields and Hide When will be recalculated. But in any case it will work faster - it will not be necessary to always update and render everything.
One can also add a method to update the specific area where Computed Subform or Embedded View is inserted.
In general, it is possible to make this more optimal and faster, and to preserve the existing API, and even expand it. The question is how deeply ready is HCL to go :)
For what it is worth, one of the major reasons Ulrich (eknori) suggests my products is because they DO allow high fidelity round-trip conversion between Notes rich text and HTML5. We do more than that at Genii Software, but converting to and from rich text to other formats is the reason for this idea being suggested.
I don't know about Ben's work but actually, there is a very very big problem around this notes rich text..
And I agree with you, IBM should invest a lot in this point
All lotus developper (for notes client app) have done nightmare about this point "rich text fidelity notes/web" and "legacy notesrichtext content" that we can't easily migrate to html5. It makes me want to abandon Lotus just because of this point.. We are stuck with notes legacy apps.. I think this is also the case for many companies who feel like IBM just emprisoned them with this notes richtext and now don't want to here about Domino.