One common request I get from clients is that they want to add dot leaders to some kinds of tables. Dot leaders are pretty common and also look great in documents but are also deceptively difficult to do in HTML. With regular typesetting software, you can fill white space with periods or other characters using a variety of methods that are relatively easy to employ. Typeset documents have set widths and fonts that don’t vary depending on external factors. HTML, on the other hand, is highly dependent on a user’s viewport settings.

Back in 2017, I wrote a post about a script that would align outline text, which would insert spacers into a formatted outline document to make it consistently spaced. This script has been in use for a few years by a few readers of this blog, and it generally works pretty well, but earlier this week I got a question about it. If a document is otherwise nicely formatted, and you only want to align a section of the document, running the script on an entire document is probably a bad idea, because there is always the possibility of it changing something that already looks pretty good. The question, then, was asking if it was possible to modify this script to run on a portion of the document, instead of the whole document.

This week, we’re taking a look at automating the subject company lookup on SC13D/G filings. This is another request from a client, but I think it provides a good opportunity to look at automation of a pretty simple task that otherwise might be forgotten and overlooked by a busy operator. This script will trigger when a user opens a project file (a .GFP file), if and only if the project being opened is of document type SC 13D or SC 13G. These are the best kinds of tasks to automate, because they are specific, and easily forgotten by an operator. If the document opened meets these criteria, the CIK of the subject company will be looked up, and the name of the subject company will be looked up on the EDGAR system and entered into the name field. This is very useful if you have an automated system that is creating .GFP files (not very hard, it’s a pretty simple file format), but you cannot guarantee that system has access to the most current names of companies. For example, if the system generating the GFP files has an outdated database of names, you would want to make sure that the subject company is replaced with current information on file open. This is where our script comes in.

This week, we’re taking another look at using Legato to enhance GoFiler’s validation. Last month, someone asked me if there was a way GoFiler could check a 10-Q project to ensure a completed XBRL file set was attached to it. Well, this isn’t something GoFiler normally checks for (since there are times when you might want to omit these files), but we can definitely use Legato to enhance the validation of the project file, so we can warn the user if they might have forgotten something. It also gives us another opportunity to demonstrate some of the project file functions, which are always useful if you’re going to be working with GFP files.

Last month, we discussed logging user submissions to the SEC in our blog post LDC 154. Well, thinking more about this, I realized it was probably not a good idea to not secure the log file. If someone makes a mistake, and files a document they shouldn’t, they could simply alter the log to show different times or users filing the document, and there is no record of it. A malicious user could easily just change what the log says! This is unacceptable and easily within our power to fix. To do so, we’re going to use a common function, the MD5 hash function.

I had an interesting issue crop up this week: a client had a file that had a 21 inch indent on a paragraph, causing problems when the file was printed to PDF. When GoFiler converts your Word file to HTML, if there are a lot of spaces or tabs on a line, it can cause GoFiler to interpret it as having a large indent level. Normally this isn’t a big deal, but if the indent ends up as large as this, it can cause rendering issues. So, I was asked if there was a way we could test for this, and figured it would be an interesting problem for a blog post.

This week, we’re going to revisit a blog post from early 2018, Validating with the XBRL Object. This was a relatively straightforward script. It hooks itself into the validate function and adds an additional layer of validation for XBRL files. Having seen a couple of issues with blank element names in XBRL causing problems this past week, I figured it would help to create a script that enhances our default validation to detect these blank names and add in a temporary placeholder name so that it can be removed.

When you file something to the SEC, there are a lot of data points that can be tracked from that event such as: if the filing was live, when the filing process began, when GoFiler began transmitting the file, and when GoFiler finished transmitting the file. This information can be gleaned different sources, including the log file and the project file metadata. However, there is no one place where filers can obtain this information. With Legato, we can set up a small script that triggers when we file a project, and simply records information about that project into a log file in the same folder as our project.

In previous blog posts, we have shown a lot of examples of tasks you can use Legato to automate. We’ve gone into detail on how these scripts work, what UI functionality is required to support them, and ways they can be improved and added upon to increase the functionality. Way back in LDC #67, we even discussed best practices that can be applied when writing applications. One topic we haven’t really covered though, is how to estimate the complexity of a task, and if it’s even a suitable task for Legato to tackle. Keep in mind we can really do anything with Legato... but there are definitely times where we should just step back, and say that a task is outside the scope of what a script should handle.

I was discussing inline XBRL with a client the other day when a thought occurred to me. GoFiler uses XDX to mark information in a document to convert it to inline XBRL at a later time, which is generally great, but it means if you have a line item on a table that doesn’t actually have a label (like a total line, for example), then GoFiler is just going to pick the standard label for that element. That’s not a bad thing, in and of itself, but if you want to customize the label, there needs to be some text on the line item for XDX to pick up. Adding hidden text to the document is a great way to add “hints” for XDX, without actually changing the look of the exported document.

 About a week ago, a client brought up a good point in a discussion we were having about inline XBRL in GoFiler. While we could generate proof files for the XBRL and proof files for the HTML, the HTML proof only showed HTML data, and the XBRL proof only showed XBRL data. The HTML proof wasn’t highlighting which facts had been tagged with inline XBRL data, because unless you view it through a special viewer, it looks indistinguishable from regular HTML. It’s a feature we will be adding in a future release of GoFiler, but why wait? Through Legato features can be added on the fly!

When working in Legato, it’s very common to come across a task that must be repeated. Several of our example scripts in this blog have used for loops or while loops. In fact, it’s fairly uncommon to write a script without one because almost any task that is complex enough that it would require a script to be written for it generally needs to iterate over something. This week, we’re going to take a look at what makes the two loop types Legato supports different, and why you would choose one over the other.

Last week, Josh discussed how we can use the ConvertFile function to convert files from their base format into HTML, in LDC #136. This week, we’re going to take that idea one step further, and create a script that can start and stop a background process that monitors a folder for files to convert. If it finds a file that hasn’t been converted, or has been modified since it was last converted, the background process will convert the file into HTML for us automatically. This creates a “hot” folder effectively, that’s monitored for jobs to do.

Whenever a task has to be done repeatedly and there’s not much thought that needs to go into running the task, it’s generally a great candidate for automating using a Legato script. I’ve been asked a few times in the past month or so how to quickly and easily insert multiple images into an HTML file. Since that’s a relatively easy task that just requires a lot of the same operation over and over again, I thought it would make a great example of automation for our Legato blog. So this week, we’ll take a look at a simple script that takes a folder as an input, scans it for images, and then inserts all of the images it finds into an HTML file.

Last year, I wrote a series of blog posts on a Page Break Manager tool for GoFiler. It allowed users to save page breaks into a style template, rename them, and delete them. One feature was conspicuously absent though, the ability to edit a page break. Well, it seems like now would be a good time to rectify that mistake! This blog post is going to go over how to add the edit function to this script. It’s also a really good example of code should be written in a fairly modular fashion, because it makes it a lot easier to come back in and edit things later. I wrote this seven months ago, I don’t really remember how a lot of the functions work exactly. Things like reading the file into a data table, or saving the file back out, are somewhat complicated, and while I’m sure I could figure out how it’s working, there’s really no need to, since those are self-contained functions within the script. I don’t need to know how they work really, as long as they do what they’re supposed to do I can simply re-use them in this new function without a problem.