256 = 666

[Lewis5FED]

So... 

Here we are agan. 

You'll recall that over the past few months, i've been posting here a lot, becoming increasingly frustrated each time. This as I watch my precious documents disintegrate before my eyes time and time again in more ways than I can recount on one, or even two hands.

It seemed a fruitless effort to try and solve the issue alone, but I did try nontheless... 

After a frustrating evening, I found myself dragging and dropping my output around my network, mostly as an exercise in impatience and self soothing.
At some point, I launched the Index file only to realize that it had started working... or, at least most of it had. 

I went down a folder level, it broke, I went up a level, some worked, I went up again, it ALL worked... 

After messing about, I copy and pasted the file names at various levels in the folder structure into Ms Word to get a character count at the levels that worked, and at those that didn't. 

After some triangulation, and without wasting too much more of your time, i'll let you know that that critical number was 256... 

I'm sure some of you already know what i'm on about, 256 a character limit or destination path limit implemented by Windows for seemingly no good reason other than "I doubt if anyone will ever exceed this"... 

This... this stupid number was the reason for 100% of my issues with Framemaker. 

The biggest issue with Framemaker here is that any *SPACE* or "_" is replaced with "%20" in the file name... one space = 3 characters. 

The result? 

File names clock up FAST... 

So, if you've got issues with your output, and you're saving to a local drive / windows machine of some sort... check the character count of the file name. If its > 256, "well there's ya problem", move it to as high a level as you can, and try and get in and shorten as many names as you can, this includes in the source files for topics, remember that spaces and underscores end up taking up 3 characters in the output destination length, so don't use them if you can avoid it.

I'll be going now. 

[Lewis5FED]

his includes in the source files *AND FOLDERS* for topics, remember that spaces and underscores end up taking up 3 characters in the output destination length, so don't use them if you can avoid it.

[Stefan-Gentz]

An understandable frustration. But … what has that to do with FrameMaker? Or Windows in that specific context of URLs/URIs/URNs? Reading this and this (+ a couple of more RFCs) should give some fair understanding.

Welcome to the World Wide Web and the sometimes challenging limitations of it 😉

[Lewis5FED]

"what has that to do with FrameMaker?"

EVERYTHING. 

If a program directly interacts with, or produces ouput for web, like FM does, I feel like this information is fairly critical. 

[Barb Binder]

@Lewis5FED. I had to read the entire thread before I understood the title. At least you have your sense of humor when things are so frustrating. 

~Barb 

[Bob_Niland]

Lewis5FED: I'm sure some of you already know what i'm on about, 256 a character limit or destination path limit implemented by Windows for seemingly no good reason other than "I doubt if anyone will ever exceed this"...

The MAX_PATH limit has been an annoyance, to ALL apps, for a long time.

Here's some history on StackOverflow:
Why does the 260 character path length limit exist in Windows?

Here's MS on hacking the Registry for LongPathsEnabled

I didn't dig deep enough to see if the 260 (or 256) is characters, or bytes, which would matter for Unicode, where a character can be 1-4 bytes (or more if fully decomposed).

[Stefan-Gentz]

Exactly. The 256 character path limit has nothing to do with FrameMaker and affects all Windows applications.

However, the issue Lewis5FED was running into is, that the path length can get even longer when you publish for the web. The reason is simply that web URLs have their own encoding requirements – e.g., a normal space (U0020) is not allowed and must be escaped/masked as %20 in a web URL.

That is, a local "my projects/user guide/chapter 1.fm" (35 characters) becomes "my%20projects/user%20guide/chapter%201.html" (43 characters) as a web URL.

So, if you manage your project in a deeply nested folder with a path close to 256 characters and then publish it into an even deeper child folder, you will automatically run into problems. More info in the two linked pages in my first reply.

For more details on the Windows Path limitations, see also these two documents:

• Windows Developer Documentation – Naming Files, Paths, and Namespaces
• Windows Developer Documentation – Maximum Path Length Limitation

[Jeff_Coatsworth]

I discovered something like this a few years ago with a FM to RH import project that would sometimes have hrefs that worked and some that didn't all in the same HTML topic. All xrefs in FM worked fine on the corresponding .fm content, so it was a real mystery as to why some got translated and some didn't. What I finally realized was that I was running up into some sort of silent limit to my FM source file+path length (I had already made my RH project take shape in a c:\projects\<project_name> folder). Once I had shortened it down, all the xrefs translated correctly.