A note on directing the output of an HTML page for printing from 1C to the default browser on the client side

Problem solved in the note

In the 1C platform for, in its client part, the ability to work with HTML pages is implemented using the “HTML Document Field” field type. This functionality is handled by the integrated WebKit browser (1). In 1C, earlier versions used the standard one in Windows IE, in a mode limited by user settings.

The company decided to change the design of the reception protocol, which provides for a header with the output of a specialist’s QR code with a link to a redirect service to the specialist’s personal profile. The placement of the QR code is fixed relative to the bottom of the page on the left and is focused on the size of the print on the A4 format.

As a result of the work carried out, including with the involvement of third-party specialists (2), (3), it turned out that when laying out the template, it is WebKit, which is built into the releases of the 1C 8.3.18 platform, that does not work with placing the footer in the specified positions.

Detailed description of the task

First of all, our database implies the absence of any script in the HTML form prepared for protocol printing, the absence of any interactive interaction. The user has already formed everything in 1C forms, filled in the necessary data.

In terms of HTML page generation, it should be noted that in the database configuration there is a Document object “Reception protocol” and a Directory object “Protocol templates”, in which the developers worked out in sufficient detail the formation of HTML template fields from the protocol data.

The structure of the directory determines the filling of the screen form of the “Reception protocol” document, while the form elements with all handlers are generated from the template modules, and are not elements of the form itself. Figure 1 shows the form in the configurator superimposed on the form of the real reception protocol.

Rice.  1: Form in the configurator against a completed form
Rice. 1: Form in the configurator against a completed form

The protocol display form in HTML is implemented by a separate object. Figure 2 shows its markup. Everything is implemented by standard 1C form elements, and CTRL + P is not intercepted and performs a standard call to the “Print” command, but the print link buttons refer to another form command for printing. The “Print” button at the top is always hidden, apparently, it should serve as an interceptor for pressing CTRL + P.

Figure 2. Print form of the full and short protocol

It is impossible to edit the text in the output field, only scrolling and printing. In addition, it is forbidden to use CTRL+P, so the user interface requires at least two extra clicks when outputting:

  • after clicking on the “print” button of the protocol, there is a transition to the short protocol tab, which is given to the client. The full protocol is not printed, but transferred by means of configuration in an HTML file to the protocol repository of the Electronic Medical Record (EMC);

  • press the link button to print in the header of the protocol;

    In the implemented algorithm, there is no A4 print preview, only a standard 1C printer selection and settings dialog.

I questioned the need for the “PrintProtocol” form in the configuration as an object. In the future, this doubt grew into confidence and made it possible to reduce the number of specialist clicks when printing the reception protocol.

Description of the operation of the protocol generation algorithm

  1. The procedure for generating data filling from the document “Reception protocol” obtains data and settings of the current template that was used when generating the document;

  2. From the template, the generating procedure receives tags for each field, in which it wraps the text of the field;

  3. The output is made starting from the “Header” fields of the template, there may be several of them, then the “Body” fields of the template, then the “Footer” fields, there are also several of them, according to the formats configured in the template.

  4. The HTML string obtained in paragraphs 1-3 is called into a procedure that takes an HTML template and, by replacing strings, inserts a header, body, and footer into the strings configured in the HTML template.

  5. The HTML template has formats for displaying HTML and printing.

Start of implementation. Changing the template filling algorithm

In the logic implemented in the Directory “Templates of Protocols” there is absolutely no possibility to mark one of the headers as the header, as well as to mark one of the footers as the footer. Therefore, it was decided to implement the elements of the new design as follows:

  1. Display the protocol header in the

    of the HTML template in the form of a table with the replacement of templates of the line like “–NameToReplace–” with the current template data;
  2. Display the generated “Header” and “Body” of the protocol in the HTML template in the table in the

    ;
  3. Display “Footer” in a table in the

    of the HTML template in the table, where the Specialist’s QR Code is the first cell and the second cell contains the generated “footer” text.
  4. Wrap the footer in a

    using a print style that will repeat the output of the
    below on every page when printed, set to A4 paper size

    Development process of a new HTML template

    We uploaded the generated complete protocol of reception, which would take more than one page, containing all possible entities for printing: text, formatted text, spurious newlines, pictures.

    With the help of editors (5), (6) and browsers (7), (8), (9), the created template was examined for on-screen display and printed out using the “Lamb” doPDF (10).

    After some insignificant number of iterations, we have achieved the output in A4 in the form we need, with the fields specified in the TOR and, most importantly, placing the QR code of a specialist in a given place when printing on various models of printers at various workplaces

    In 1C, in general layouts, the authors of the configuration placed an object called “HTML Template” containing the “old template”.

    To maintain backward compatibility, it was decided to implement a new mechanism for generating the HTML form of the protocol in the extension, in which a new object was created in the general extensions with the name “HTML Template with Footer” (10), into which the code of the developed template was copied. Here is the part of the style responsible for printing the HTML page:

      @page {
            size: A4;
            margin: 0mm 0mm 0mm 0mm;
            margin-top: 10mm;
            margin-bottom: 10mm;
            margin-left: 2mm;
            margin-right: 5mm;
        }
    
    
        @media print {
    
    
            thead {
                display: table-header-group;
            }
    
            tfoot {
                display: table-footer-group;
            }
    
            button {
                display: none;
            }
    
            body {
                margin: 0;
            }

    Our mechanism was also moved to extension (11) by replacing the work of standard procedures with extension procedures. A restriction on the date of printing was introduced in this way: “If the date is less than 07/27/2022”, then regular HTML generation works, otherwise the “new” form of the template works. This is due to the peculiarity of printing previously saved protocols, since even the HTML template from the configuration is applied to their display, instead of storing the generated and printed document with styles and other entities.

    It is necessary, when referring to history, to use the “old” printing mechanism.

    After launching our implementation of the formation of the receive protocol, the form for viewing the protocol opened, where we saw that our template was applied to both the full protocol and the short one.

    Everything looked good on the screen until I started printing on A4. The footer was placed in an arbitrary place in the reception protocol, styles changed functionality or were not applied at all.

    At the same time, using the protocol generated in 1C HTML and opening it in any popular browser confirms that the markup works, the footer falls into place, hence the output for printing by job parameters is suitable.

    All the efforts of our IT department and all available colleagues were thrown into debugging, who tried to apply various solutions for correctly printing HTML text from 1C. It took a week to make sure that our actions will not bring a positive result.
    For my part, I convinced the head of the department that printing to the browser would be more practical than using the completely unnecessary “Print Protocol” form, in which there is no preview display, extra actions are required that do not carry any semantic load.

    Implementing printing of any HTML template to an external browser

    A scheme of the protocol printing algorithm through an external browser has been developed:

    1. Formation of a short HTML protocol for printing and a long one for saving in the EHR;

    2. Saving a short protocol to a temporary file with the addition of a browser print control line (12);

    3. Sending a command to the default browser to open the saved HTML file (13);

    4. Deleting the generated file at the time of closing the acceptance document form;

    5. Sending the complete protocol to the EMC after fixing the transfer for printing in the browser.

    As a result of executing the commands written at the end of the short protocol file (12), the default browser opens a print preview window and printer selection, which allows you to evaluate the appearance of the protocol before printing (which is very lacking in 1C) and print using standard means.

    Conclusion obtained from the implementation of the task

    “It is not always worth using the functionality offered by the platform, but one should consider a set of applications installed on the user’s workstation to create a comfortable atmosphere for the system to function”

    Materials for the article

    1. WebKit site: https://webkit.org/

    2. https://freelance.habr.com/freelancers/anvarjon-hujamov

    3. https://freelance.habr.com/freelancers/Skeaper

    4. Our HTML Template https://github.com/rf-bessome/1c/blob/main/shablon_protokola.html

    5. Text editor Notepad++ https://notepad-plus-plus.org/

    6. Sublime Text 3 Editor https://www.sublimetext.com/

    7. Chrome browser https://www.google.com/intl/ru_ru/chrome/

    8. Edge Browser https://www.microsoft.com/en-us/edge

    9. Mozilla Browser https://www.mozilla.org/

    10. PDF Generating Tool: PDF24 https://www.pdf24.org/

    11. Information from the 1C website about working with extensions: https://its.1c.ru/db/v838doc/bookmark/dev/TI000001513

    12. Line for sending to print and then closing the browser window:

    "   <script type=""text/javascript""> document.execCommand('print', false, null); window.close(); </script>"
    1. Printing to the default browser, line 5:

    &НаКлиенте
    //процедура печати
    ИмяФайла = ПолучитьИмяВременногоФайла("html"); 
    //запись шаблона в файл "ИмяФайла"
    ЗапуститьПриложение(ИмяФайла);
    

    Thank you for your attention!

Similar Posts

Leave a Reply Cancel reply