Hi, I am using ViewerHtmlHandler.GetPages in .NET to retrieve the HTML of PDFs in version 17.11.
However, when I tried this on a fillable PDF form, none of the content I filled in and saved is being included in the HTML generated from the method. Regular PDFs seem to be working fine. Is this an ongoing bug or fixed in a newer release?
Thanks.
Please share with us the source code you are using to render the document as well as the problematic PDF document so that we can investigate you reported issue at our end.
We are using the below code to generate the html for each page of the document.
I have attached the fillable PDF form.TestFilledForm.pdf (298.8 KB)
var fileId = "TestFile1";
var page = 1;
var documentStream = GetDocumentStream(fileId);
var cfg = new ViewerConfig
{
StoragePath = _storagePath,
CachePath = _cachePath,
UseCache = true
};
var htmlOptions = new HtmlOptions()
{
PageNumbersToRender = new List<int> { page },
PageNumber = page,
CountPagesToRender = 1,
HtmlResourcePrefix = "/api/" + fileId + "/" + page + "/"
}
var _viewerHtmlHandler = new ViewerHtmlHandler(cfg);
return _viewerHtmlHandler.GetPages(documentStream , fileId, htmlOptions);We are able to reproduce your reported issue at our end. The issue has been logged into our Issue Tracking System as VIEWERNET-1977 for further investigation. We shall keep you notified in case of any updates.
While we are working to investigate and fix your reported issue, as a workaround you can set the RenderComments property of HtmlOptions to true and it will render the form field values without any issue.
var htmlOptions = new HtmlOptions
{
RenderComments = true
};I just tried this workaround, however, the issue is still not resolved and the values are not included in the HTML. Please let me know when a fix has been released. Thanks.
It could be possible that the API is fetching the cached HTML pages at your end. Therefore, we’ll recommend you to please clear GroupDocs.Viewer’s cache folder that you are using in your application and try rendering the document again. Furthermore, for reference, please download this sample console application that is using HtmlOptions.RenderComments property as a workaround of your issue. The PDF file is located in bin folder and the generated HTML files will be saved in bin\Debug\output folder. Hope it helps.
Yes, it was the cache causing the issue and this is working for me locally. Thanks.
I will need to review whether rendering comments in the HTML viewer is an acceptable workaround for now until the fix is released. But I saw on the documentation that Rendering Without Annotations is not supported until 17.3 and we are on 17.11.
If we default HtmlOptions.RenderComments = true, would our HTML rendering be affected at all? What are the side effects? I don’t see the comments generating in the HTML when I tried your sample application.
It’s good to know that your issue is resolved now.
Yes, the feature of rendering annotations in the PDF documents is supported since v17.3 and it is available in the later versions including v17.11.
In fact, there is no side effect of using HtmlOptions.RenderComments = true. The only difference will be that the annotations in the source PDF document will also be included in the generated HTML pages.
The PDF document you have shared earlier doesn’t contain the comments in that, therefore, the output HTML doesn’t have any comments. In case you have updated that document or using some other document then please share that with us so that we can check if there is an issue in rendering the comments.
What I am seeing is that the visual representation of the comment is rendered in the HTML output, but the actual content of the comment does not render unless it is plain text comment which its visual representation is the text itself.
For example, if I use a Drawing Comment or Drawing Tool Arrow comment on my PDF and render the HTML, I see the Drawing and the Arrow in the browser, but I do not see the actual comment itself. If I hover over those comment items, there is no code/javascript rendering out a popup with the comment text. If it is a strike through comment, I only see the strike through and not the comment in the rendered HTML.
I have uploaded the same PDF I have been testing with but with several different comment types to see how they render.
I want to confirm if this is the behavior I should be seeing and if it applies to other file formats that support commenting and annotations.
Thanks.
TestFilledFormWithComments.pdf (319.9 KB)
We are able to observe your reported behavior where the content/text of the comments doesn’t appear in the rendered HTML. We have logged it in our Issue Tracking System as VIEWERNET-1982 for further investigation. We shall keep you updated you as soon as we have any information for you.
Thanks @usman.aziz. Do both these defects exist in the latest version of the GroupDocs library?
I wanted to know if this was one of our possible options i.e. upgrade the version. But I noticed there are breaking changes after 18.6 and we would need to spend time updating our codebase.
Yes, we observed both issues in the latest version as well. However, the issue related to the form field values (filed as VIEWERNET-1977) has been resolved and its fix will be included in the upcoming version 19.4. We shall notify you as soon as v19.4 is released.
Yes, you will observe some breaking changes while upgrading to the latest version. You can consult the release notes of the API to know about the changes that have been made to the API. In case you would face any issue in the migration process, please feel free to let us know and we’ll do our best to resolve that.
We have an update for you regarding the rendering of comments in PDF documents (logged as VIEWERNET-1982). At the moment, the API only supports the plain text comments and the rendering of the comments attached to the annotations or drawing markups (such as Sticky Notes, Strikethrough, Highlighted Text, etc.) is not supported.
Would you please share with us the way you expect to see the comments attached to annotations and drawing markups in the generated HTML pages?
Comments were actually not a feature we were originally using. It only came into the discussion because the workaround in 17.11 required turning on the rendering of comments. The workaround would fix the form fields but now comments would be rendered. I wanted to review the impact to our users if they actually had comments in their documents since it was not rendering before. For example, I wouldn’t want the comment content and document content overlapping and becoming illegible.
On another note, I did not see VIEWERNET-1977 in the 19.4 release notes. Will it be in 19.5 now or 19.4.1? Or is it filed under VIEWERNET-1939 which sounds similar from the description?
Thanks for sharing the requested information.
In that case, upgrading to v19.4 will fix the issue of missing form field values and you will not have to use the workaround anymore. Hence, the comments will not be included in the generated HTML pages.
Thanks for pointing this out. We have updated the release notes and corrected the issue ID.
The issue you have faced earlier (logged as VIEWERNET-1977) has been fixed in this release.