Master Font Variant file - too many duplicate copies

Question

Hello all - 
 I hope there is an easy answer to this question and that I've just missed something in the SDL documentation. 
 I have the Master Font Variant file _fv_filename.sde set up in the D:\XPP\sd_liz\Ljobfonts\ folder. It is there with all the _fgs_12345.sde and the _kp_12345.sde files. 
 All of our jobs work from the same collection of font variants but we have different Spec Libraries for various styles (different page layouts, hyphenation rules, etc.). 
 I've now ended up with 50+ copies of the Font Variant _fv_filename.sde file. Each time I add a font, I update the Master Font Variant file and then I have to copy it to 50+ places. 
 Surely, there's a better way. 
 The local job ticket asks for the Spec Library, the Standard Style, the Font Variant Spec [which is always the same], the XyMacro Spec, the Font Width Library [which is always the same], and so on. If the redundant copy of the Font Variant file is not in the local folder, then the jobs don't work. 
 
 So, should the Master Font Variant file be located in a different place other than the D:\XPP\sd_liz\Ljobfonts\ folder? 
 Should the Job Ticket be set up differently? 
 Thanks for your help!

Chris Leggett · Accepted Answer

Looks like you need a script to update from the master to all the other instances!

Bart Terryn · Answer

Chris, 
 
There is a way out of this (although this is not recommended practice) 
You copy (=overwrite) your _fv_filename.sde as _fv_sys.sde into the Lsyslib. 
(you probably want to copy the existing _fv_sys.sde as _fv_sys_org.sde before you do this!) 
 
The font variant spec is looked up as any other spec. 
So if the _fv_filename.sde can not be found in the spec library, the system will look for a file called _fv_sys.sde. 
It will first look in the spec library for that file and if it can not be found it will look for this file in Lsyslib. 
 
Like that you will only have to update the file in one location. 
(you will need to remove ALL the existing _fv_filename.sde files though) 
 
In the future you can simply update the _fv_sys.sde file. 
 
Now why is this not recommended? 
Because it is not recommended to change any of the sys files in the Lsyslib. 
As these are the fallback base files for the system and SDL can decide to deliver new versions of these files at any time. 
So you probably want to keep a backup copy of your modified _fv_sys.sde file somewhere in a safe place in case it does get overwritten. 
 
Not recommended but in your case an acceptable compromise (I think - SDL engineering might disagree with this)

Jonathan Dagresta · Answer

Hi Chris, 
 Just to add some additional information to Bart's suggestion, which IMO is not a bad suggestion for this particular file. 
 The _fv_sys.sde file that is delivered/installed with XPP is only installed to the /sd_liz/xylibrary/Lsyslib/_fv_sys.sde location. 
 Then the (core release) install would copy that xylibrary file to /sd_liz/Lsyslib only if there is not already a _fv_sys.sde file located there. 
 So actually, this particular _fv_sys.sde file in Lsyslib is considered to be customer customizable (and will not automatically be overwritten by XPP installs). 
 Yes, as Bart pointed out there are many files in Lsyslib that are not considered customizable and that would be overwritten by an XPP install - examples of such are the _xy_sys.sde file and the style bundle (if/pl/xx/hj/pc/ps/pt/ht) files and other files as well. 
 The only caveat I can think of to customizing _fv_sys.sde in Lsyslib is that if doing a "fresh" install you would of course get the XPP-delivered version of _fv_sys.sde in Lsyslib and then you would have to copy in your customized version. I'm sure you agree that this is obvious behavior in this scenario. 
 If you have any questions on whether any Lsyslib file is considered customizable or not, and you cannot find the answer in the XPP documentation, then feel free to open a ticket with Support to get an answer (or you can post such questions as well).

XPP > XPP

Master Font Variant file - too many duplicate copies