<commit_before><?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE concept PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">
<!--  This file is part of the DITA Open Toolkit project. See the accompanying LICENSE file for applicable license.  -->

<concept id="best-practices-pdf-customization-plugins">
  <title>Best practices for custom plug-ins</title>
  <titlealts>
    <navtitle>Best practices</navtitle>
  </titlealts>
  <shortdesc>Adhering to certain development practices will properly isolate your code from that of DITA Open Toolkit.
    This will make it easier to you to upgrade to new versions of DITA-OT when they are released.</shortdesc>
  <conbody>
    <ul>
      <li>Use a properly-constructed DITA-OT plug-in.</li>
      <li>Use a version control system to store your code.</li>
      <li>Never modify any of the core DITA-OT code.<note type="tip">You may want to set the permissions on default
          plug-in directories such as <filepath>org.dita.pdf2</filepath> to “read-only” to ensure that you do not
          accidentally modify the files within as you develop your customized plug-in.</note></li>
      <li>Avoid copying entire DITA-OT files into your customization plug-in. When you only copy the attribute sets and
        templates that you need to override, there is less risk of impact from new features or fixes in the base code,
        making your code more stable and easier to upgrade between releases.</li>
      <li>If you only need to change a few attribute sets and templates, you may prefer to store your overrides in
          <filepath>custom.xsl</filepath> files, or a simple folder hierarchy within your custom plug-in.</li>
      <li>In cases that require substantial customizations, you may prefer to organize the files in a folder structure
        that mimics the hierarchy of the default plug-in you are customizing. This facilitates comparisons with the
        default settings in the base plug-in and makes it easier to migrate your changes to new toolkit versions.</li>
      <li>Upgrade your customization plug-in to new versions of DITA-OT regularly. Do not wait through several major
        releases before upgrading.</li>
      <li><div conkeyref="reusable-components/plugin.rnc"/></li>
      <li>
        <p>For XSLT customizations, use a custom namespace for any modified template modes, template names, attribute
          sets, functions, and variables. This helps to clarify which portions of the code are specific to your<commit_msg>Use ¶ in list items for consistent leading<commit_after><?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE concept PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">
<!--  This file is part of the DITA Open Toolkit project. See the accompanying LICENSE file for applicable license.  -->

<concept id="best-practices-pdf-customization-plugins">
  <title>Best practices for custom plug-ins</title>
  <titlealts>
    <navtitle>Best practices</navtitle>
  </titlealts>
  <shortdesc>Adhering to certain development practices will properly isolate your code from that of DITA Open Toolkit.
    This will make it easier to you to upgrade to new versions of DITA-OT when they are released.</shortdesc>
  <conbody>
    <ul>
      <li>
        <p>Use a properly-constructed DITA-OT plug-in.</p></li>
      <li>
        <p>Use a version control system to store your code.</p></li>
      <li>
        <p>Never modify any of the core DITA-OT code.<note type="tip">You may want to set the permissions on default
            plug-in directories such as <filepath>org.dita.pdf2</filepath> to “read-only” to ensure that you do not
            accidentally modify the files within as you develop your customized plug-in.</note></p></li>
      <li>
        <p>Avoid copying entire DITA-OT files into your customization plug-in. When you only copy the attribute sets and
          templates that you need to override, there is less risk of impact from new features or fixes in the base code,
          making your code more stable and easier to upgrade between releases.</p></li>
      <li>
        <p>If you only need to change a few attribute sets and templates, you may prefer to store your overrides in
            <filepath>custom.xsl</filepath> files, or a simple folder hierarchy within your custom plug-in.</p></li>
      <li>
        <p>In cases that require substantial customizations, you may prefer to organize the files in a folder structure
          that mimics the hierarchy of the default plug-in you are customizing. This facilitates comparisons with the
          default settings in the base plug-in and makes it easier to migrate your changes to new toolkit
        versions.</p></li>
      <li>
        <p>Upgrade your customization plug-in to new versions of DITA-OT regularly. Do not wait through several major
          releases before upgrading.</p></li>
      <li><div conkeyref="reusable-components/plugin.rnc"/></li>
      <li>
        <p>For XSLT customizations, use a custom namespace for any modified template modes, template names, attribute
          sets, functions, and variables. This helps to clarify which portions of the code are specific to your
{'fraction_non_alphanumeric': 0.07967511119706053, 'fraction_numerical': 0.0015470895378070005, 'mean_word_length': 3.267326732673267, 'pattern_counts': {'":': 0, '<': 95, '<?xml version=': 2, '>': 95, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 2}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '6699140', 'n_tokens_mistral': 1392, 'n_tokens_neox': 1324, 'n_words': 643}