How to type a colon in the name fields?
I'm trying to list the time (ex 12:55) in a watermark field and it won't let me. The default time is HH-MM which just ends up looking like a zoom focal length range (12-55). I've tried separating the elements into 2 parts with HH and MM, but then it won't let me manually type in the colon.
-
Experiment shows that you can use a semi-colon, and various other punctuation marks, but you can't use a colon. I have no idea why, but I suppose that : must upset the OS somehow. I'll see if I can find out.
You could also consider using h and m, so that your time showed as 12h55m.
Ian
0 -
Colon by itself is a character forbidden in filenames or paths, so "name fields" in Capture One will try to avoid it, including not having any colons in default tag formatting. It seems that watermark field uses the same tags despite not having the same limitations - for simplicity of implementation, I think. On the other hand, dunno why watermark field itself would forbid using colons, I have tested on 16.2.5 Windows and cannot confirm there is any problem, as I have typed in the "[Image Time (HH)]:[Image Time (mm)]" format and it worked, with "16:33" being shown on the sample exported JPG.
0 -
Thanks Ian! I'm also on a Mac. The "h" and "m" is a great suggestion in the meanwhile.
Marcin, the problem must be Mac OS based then. Thanks!
0 -
Marcin Mrzygłocki the colon character is not forbidden in filenames. lots of people name files with time stamps that include colons for hh:mm:ss. there is a token for it in capture one. forbidding us from typing it makes no sense.
0 -
Colon characters are generally forbidden: https://stackoverflow.com/questions/1976007/what-characters-are-forbidden-in-windows-and-linux-directory-names
Even though *nix systems allow using them, I can reference a dispute over fullwidth characters as alternatives to forbidden characters in filenames - a counterargument to my suggestions was that fullwidth characters would confuse non-Asian recipients, as they would have no idea how to type them or would be confused by "seemingly impossible" characters in files they receive. I will reuse this argument - even though these characters are generally OK for *nix users, even for them they might a bit burdensome to handle properly, while Windows-based recipients of files with such filenames would have a nightmare of not being able to access the files AT ALL, OS would deny any operations like opening, copying, renaming*...
So it would be likewise best advised to follow this guideline when handling files or paths, and this is what Capture One does in a "better safe than sorry" fashion. It was extended to watermarks by accident, but at least on Windows there is a workaround of building the string manually as I have tested above.
*Apart from almost forgotten 8.3 filename hack.
0 -
That is a Windows legacy limitation for which there is no justification. We can blame Microsoft for holding on to such dated restrictions.
0 -
That's NOT legacy and is not only implemented, but apparently still in use:
https://en.wikipedia.org/wiki/Filename#In_Windows
https://en.wikipedia.org/wiki/NTFS#Alternate_data_stream_(ADS)
0 -
Yes it’s still a limitation but without justification. That’s my point. It’s a holdover. Microsoft could update their file system if they chose. It has no justification.
0
Post is closed for comments.
Comments
8 comments