Hi
DOpus seems to hide a space in certain areas for folders and files.
See attached example for the folder (missing a space) v the lister which shows the 'missing' space. Also a screenshot of how windows explorer can see the space in both panes (folder and file view).
It is annoying as I sometimes add what I think is a missing space, but then in other apps I see there is 2 spaces.
It seems to happen when there is a space then a hyphen " -"
**
**Cheers
Dean
I can't reproduce what you're seeing so far:
But I wonder if you're looking at the same thing in all four places in your two screenshots.
In the Opus screenshot, the folder tree on the left is showing a branch which looks like it is:
Desktop > Fonterra Co-operative Group Limited
That branch is not selected, so it can't be what the file display on the right is showing. And indeed the file display is in a different path:
C:\Users\cappdean\Fonterra Co-operative Group Limited
What happens if you expand the same path in the tree on the left? Are the paths correct there?
Do you know how you got that folder in that part of the folder tree? It would not normally be there, so it has probably been added there by a piece of software. That software may be the thing which is removing the spaces when Opus asks it to enumerate the folders below that branch of the tree.
The File Explorer screenshot is too cropped to see exactly where either side is pointing. Was it pointing to the same place? If not, what happens if you do?
Hi Leo
Thanks for your reply.
They are the same directories, just different ways to get there direct v shortcut in favs - it is a what O365 creates on your local onedrive (I think it is in onedrive account) when you sync a sharepoint site. Both sides of the pane are the same directory structure. I have added another pic to show the identical path now - same results.
The screenshots from DOpus and Win Explorer are from the same points. I have added another File Explorer screenshot which show the path and the folder names with the space
The DOpus picture is the the same path and directories in both panes, but as you can see the left folder pane shows a 'missing' space, whereas the right lister pane shows there is one.
The folders are O365 SharePoint synced folders/files and I added them then to my favourites in DOpus for easy access.
Cheers
Dean
If you navigate to that folder in the tree via C:\ -> Users -> cappdean do you see the same thing?
Does it make any difference if you turn off Preferences / Folders / Folder Display / Display localized folder names ?
Hi Jon
I turned it off, refreshed the view and even restarted DOpus. Still the same results.
Cheers
Dean
If you click one of the names in the tree and press F2 to enter inline rename mode, copy the whole string to the clipboard and then paste it into Notepad, is the space missing in Notepad as well?
It looks ok in Notepad. Results are:
IT PMO - CA PPM Support Material
Note; the screenshot of Dopus - shows the folders with the missing space on the left, but the same folders on the right hand side show the space. It is there, just the folder view is hiding it.
I have also made sure it is not a special character, e.g. Shift + Space
Is the tree using a different font to the file display?
File Display is Calibri light 11
Folder Tree is Calibri light 11
File Display Groups is Segoe UI
Not sure if these are the right ones
It's the font. I see the same thing when I change the tree to use that font.
It looks like there is a space there, but the font's kerning is set up so a space after an O character is very narrow.
The tree and file display may use slightly different APIs to render their fonts, which is why it doesn't happen in both places. (In fact, if you push F2 to edit the folder name in the file display, it happens there as well when using the same font.)
Change to another font. That one's no good. 
but, but it's my current favourite 
I will change it though as it is an annoying side effect. PS: It affects all dashes after any preceding character, not just an O
Any chance the API will be adjusted to produce the same results as the lister?
Well done chasing down the cause!!
Case closed
The API is not incorrect. Windows just has two ways of rendering fonts, one which does tighter kerning than the other. (I don't know why, to be honest. I think one might do subpixel kerning and the other doesn't, but it can result in very large differences with some fonts. Maybe the font has bad kerning data that only one API uses, and it was designed with the older API in mind so they didn't notice when making the font.)
I think Explorer uses the API that's triggering the problem itself in its folder tree, you just can't see it as you can't change the font to that one there.
The font is what's incorrect here.
I can't change the font in file explorer without a registry edit (locked down at work), so will see if I can do at home to reproduce in File Explorer
Hi
Just thinking, if it is the API, wouldn't the same font have the same issue in both the folder tree and the file listing? One displays ok and the other doesn't.
There are two different "base-level" text output functions in the Win32 API, DrawText() and TextOut(). One triggers the issue and one doesn't.
