FrameMaker 2019 HTML5 generated output problems

[DHTML]

I have been experiencing problems with HTML5 generated by FrameMaker. When I open a Fm book and generate HTML5 from it, the HTML5 is OK. But if I then edit a .fm file in my book, update the book, and regenerate HTML5, then the output HTML5 does not give me the content from the edited .fm file but the pre-edited .fm instead. Odd.

If I then save my files, close FrameMaker, re-open and regenerate HTML5, all is OK. Odd.

Furthermore, I have found that the problem seems to depend on whether I am logged into my company laptop as myself or as a temporary user (temporary user has been set up to be the same as my own user login).

But I find that:

• my own user login gives me my HTML5 issue;
• yet the temporary login does not.

Odd.

Also, I have discovered that, with my HTML5 problem condition, if I rename the .fm file that is not properly been shown in my HTML5 output, and then update the book and  re-generate HTML5, then the HTML5 output does reflect the .fm file source.

I have tried Win 7 and Win 10. I have the latest rev of Fm2019.

Colleagues do not experience the same problem.

I need to use my own login for many other reasons and

I cannot keep on closing and restarting FrameMaker because I need to interactively generate HTML5 and

I cannot rename all .fm files in a book every time I generate HTML5.

Does anyone have any clue what is happening?

[frameexpert]

Are your FrameMaker documents open in FrameMaker when you update the book? If so, the documents won't be automatically saved. Make sure you save your documents before rerunning the Publish command.

[StudioSm]

What is happening is that FrameMaker/Windows can not figure out how to clear memory between each iteration of the generation of html5 content. This is what helps:

• Generate HTML5
• Close FrameMaker
• Close browser and make sure your browser is set to not store old sessions
• Do a search on c:/ for *.tmp files and delete all *.tmp files which you are allowed to access. The rest does not matter and you can keep them
• Delete the last folder with generated output or switch to a new folder for the next iteration
• Restart FrameMaker
• Do a new Publish to HTML5
• ... and so forth next time around

The reason why changes do not reflect in the generated output is that FrameMaker picks up old settings which lie in the temp folder and serves them as you new output. It is quite annoying and I have posted it as a bug.

[Gizmo-42]

• Generate HTML5
• Close FrameMaker, browser, etc.
• Restart FrameMaker
• Do a new Publish to HTML5
• ... and so forth next time around

This sounds rather excessive for an authoring tool.

I have 30 files using shared resources with some variations.  A minor change in one of the resources - say a copywrite page - should be updatable with one press of a "publish all" button. 

[StudioSm]

I have had these issues. That does not necessesarily means that everybody else will have them. And they don't as far as I am aware of.

Win7, which I am running, is old and Microsoft has just recently sent it to the secret elephantine churchyard of outdated software. You are better off trying the process out for yourself and checking whether it works for you.

[DHTML]

Hi. I do not have any .fm files open when I am generating my HTML5 output.

I save, close .fm files and then do a book update before the publish HTML5 step.

As I posted, the HTML5 problem seems to affect me when I am logged in as myself and it does not affect me if I log in as a temporary user. My workflow is the same each time.

[DHTML]

Hi StudioSm,

I had read your posting when I first experienced the issue. Closing down FrameMaker and restarting it and re-opening your book and regenerating the H|TML5 does then generate correct HTML5 once but once and once only. You must do that for every Publish you want to do. That is what I have found. That seems to fit in with your experience.

It does mean that interactive HTML5 publishing is ruled out or is incredibly slow. As you must know.

Your description about old settings used by FrameMaker sort of rings true though. Something like that would explain what is going on. Along with Adobe support and IT at my company, I have conducted tests clearing user folder files, using different Windows OS's (7 and 10), with different laptop machines, and with different login user names. Each time, we find that if I log in as me, I experience an HTML5 issue. If I log in as a temporary user, who is even set up with the same privileges as me, then I do not experience such an issue. 

There is something that FrameMaker must be using which is linked to my login, for some reason, which is causing this anomalous Fm HTML5 behavior.

[StudioSm]

Hi DHTML

Another issue with publishing is url's.  I have experienced that having a unicode character in the path, like æøå or anything else outside of ascii will cause problems. Meaning that if your user url is something like C:\Users\insertusername_æøå you will have problems. The same goes for fm file folders residing in that kind of url's or output folders. Publishing to C:\Users\æøå will cause problems as will making project files with that kind of url's.

I don't know whether that might be the cause of the differences you experience between the two kind of user profiles - but worth a look, perhaps.

[davidcfrye]

Assuming the HTML output is not on the local machine, hit CTRL+F5 while looking at the HTML output.

[DanReedVistair]

If the problem is following your Windows account around, then it must be some FrameMaker setting in your AppData\Roaming directory.
Try (backing up then) deleting the AppData\Roaming\Adobe\FrameMaker folders and see if that helps.

[This will destroy all of your user settings in FM]

[DHTML]

Hi DanReedVistair,

I took a copy of my Appdata/Roaming FrameMaker user folder and deleted the contents of the original.

I retried my test book. No change, it still show my HTML5 problem.

(If I remember correctly, this was the first thing that Adobe support asked me to do when I originally contacted them about my issue (a while ago).)

While trying to gather evidence on this, or while trying to find a work-round, I have tried new logins and new laptops and new OS's, which (I assume) would all generate fresh, new user folders etc. Problem still occurs though, pity.

Thanks for the heads up. 

[DHTML]

Hi Davidcfrye

My HTML5 output is nornally on my C drive, not remote.

I tried the Ctrl-F5 and it did not change the browser display.

If I look in my output folder at the HTML5 file relevant to the .fm file of my book which is being wrongly shown in the HTML5, I find that the wrong, out-of-date text is also in that HTML5 file. So the browser seems to be showing the HTML5 OK. It is the regenerated HTML5 file from FrameMaker that is at fault. 

[davidcfrye]

What happens if you publish round 1 to location A and then round 2 to location B (a fresh, never used location)? What happens when you publish to a remote location on your network? Have you eliminated the previous poster’s unicode suggestion?

[DHTML]

Hi Davidcfrye,

I asked IT to look for unicode characters in my user name and in user path urls. Nothing found.

My usual workflow is to publish to a new fresh folder each time now. Each time, the HTML5 issue surfaces, wher HTML5 files show old content.

The only thing I have found is that when I login as me, I get my HTML5 issue. And while investigating this HTML5 problem, my IT dept had supplied me with two temporary logins and both do not show this HTML5 issue. It is only my own login.

But, running out of ideas, someone said that one obvious difference between my user login and the two temporary logins is the user name length (mine was 12 characters long, the two temporary logins I had been trying were 6 and 8 characters). So IT dept supplied me with a 12-character temporary login. I tried this and this did give the HTML5 issue. So that suggests an HTML5 problem specific to user name length. I have asked Adobe about this and have had no answer yet.

[davidcfrye]

Wow. Super weird issue. I wonder what the total character count of the path to your output folder is. I believe the max length for Windows systems is 256 characters. So if your path includes your username and you're near the max character count, that might contribute to the issue. If you try saving to some other location, further up the path, I wonder if you'd still have the issue. I can't imagine many reasons why name length would matter.

[StudioSm]

Length of path is a real issue and one I have stated towards Adobe last year too. If you come above 256 characters, you are in trouble. And the trouble may arise in specific files within the project.