Master Font Variant file - too many duplicate copies

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.

Screenshot of Trados Studio's Local jt job window showing fields for Spec Library, Standard Style, Font Variant Spec, XyMacro Spec, Font Width Library, Xchange Library, Input Tran, Output Tran, and Dictionary Library with various file names and settings.

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!



Generated Image Alt-Text
[edited by: Trados AI at 5:07 AM (GMT 0) on 5 Mar 2024]
emoji
Parents
  • 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)
Reply
  • 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)
Children