Tag: Text Collector

On hosting a video

When I published my one and only video on how to use Text Collector, YouTube was friendlier to small-time creators than it is today. In the end cards, for example, I could link to my Play Store listing, but that’s no longer allowed. My end cards are grandfathered, but I can’t change them unless I want to lose the link. Much worse, a couple years ago, Google started playing advertisements before my video, a significant change quietly tucked into a November 2020 terms-of-service update:

Ads can now appear on videos from channels not in the YouTube Partner Program (YPP), and we will begin gradually placing ads on brand safe videos… Because these channels are not in YPP, there is no creator revenue share, but creators can still apply to YPP once they hit the eligibility criteria, which remains the same.

For now, YouTube “Partners” can still demonetize videos if they like, but I don’t qualify for the YouTube Partner Program and probably never will. So viewers are stuck with seeing a pre-roll advertisement on my video and there’s nothing I can do about it short of taking down the video.

This isn’t really surprising. Google isn’t much more than an advertising broker, so they pepper their properties with ads. Hosting isn’t free and it doesn’t bother me that they make a little money on ads in the sidebar, but interrupting my content is another level of nuisance.

This is the same video that appears at the top of my listing on the Google Play Store for Legal Text Collector.

Play Store listing

Google’s strategy being a Web of monopolies, they require that the video on my Google Play listing be hosted on YouTube and their own guidelines concur that I shouldn’t have ads:

Disable ads for your video to be shown on Google Play. When users browse Google Play, we want them to see a video about your app, not someone else’s ad, as this can be confusing for users.

Wish I could disable ads, Google. I guess one hand can wash the other without knowing what the other’s doing.

So what are my alternatives?

YouTube’s stranglehold on Internet Video makes removing my video from YouTube unrealistic. In addition to YouTube, I’ve hosted the same video elsewhere now for more than a year, yet a Bing video search for “Legal Text Collector” only finds the YouTube version.

Bing shows 'There are no results for "legal text collector" -site:youtube.com'

I considered adding a block of offensive terms to the video description, hoping that the Algorithm would remove ads in the name of brand safety, but more likely I’ll just get unsavory advertisers.

No, despite the apparent futility, the best I can do is give people some alternative place to watch.

Vimeo

Vimeo is the best-known competitor, in the sense that a gnat is a competitor to an elephant, and they promised not to do this:

Vimeo never puts ads before, after, or on top of videos. However, we do have limited display advertising below the player on some vimeo.com pages.

They’re targeting those of us who wants to host a video that isn’t a product unto itself, but an extended advertisement for a product, so I put my video on Vimeo.

How did it do? In its three years on YouTube, my original video accumulated just shy of fifty thousand views, or roughly thirty per day. In nearly two years on Vimeo, it’s received twenty-eight, total.

WordPress

I can drop the Vimeo link into a WordPress article and WordPress shows the video, easy:

But wait. In this blog, I don’t host pictures on a third party site: I can upload pictures directly to WordPress, I should be able to do the same with videos. And indeed I can, but it’s awkward. On WordPress.Com, the Classic editor lets me inline a video with the wpvideo shortcode:

But there are a couple problems. First, it doesn’t let me upload my .webm version, for “security reasons.” For those readers not steeped in computer jargon, “security reasons,” is an idiom  meaning, “can’t be bothered.”

WordPress.com’s rejection of .webm is a merely a nuisance; the important problem is that the shortcode provides no way at all to add captions1. So I have to abandon the shortcode and though I prefer to pretend the new “Gutenberg” editor doesn’t exist, Gutenberg does at least let me insert a video with captions:

At least, it lets me add captions to a video today. When I first drafted this post in 2021, it didn’t.

For a long time, the only way to add captions on a generic WordPress installation was via a tortuous workaround. With that in hand, I followed the steps its author generously called “needlessly opaque,” and I found myself blocked as WordPress.Com banned subtitle track upload, again for “security reasons.”

I wonder what they have to say for themselves.

Diversity typically includes, but is not limited to, differences in … physical disabilities and abilities… we welcome these differences and strive to increase the visibility of traditionally underrepresented groups.

…

we’ve established a Diversity and Inclusion committee

Hrm.

Captions on a video aren’t an esoteric issue, people. Sadly, the eight years between WordPress getting video hosting ability and being able to add captions on WordPress.Com is all too typical. Consider that to this day, Medium doesn’t allow tables, which is why so many Medium articles use images where they ought to use tables; for that matter, Medium didn’t even allow alt text on images for years. Why not punch a blind guy while you’re at it.

Self-hosting

But wait. I have a website for Legal Text Collector already. It serves files and videos are nothing but files. Browsers display them with a simple tag:

<video controls width=600 poster=_static/video/youtube_banner.png >
  <source src=_static/video/howto.webm type=video/webm >
  <source src=_static/video/howto.mp4 type=video/mp4 >
  <track label="English" kind=captions srclang=en src=_static/video/howto-en.vtt >
</video>

Html doesn’t yet directly support “adaptive bitrate” streaming: the way that a video starts fuzzy and then gets more clear as the buffer catches up, but I don’t think I need it and if I really wanted it, there are JavaScript libraries out there that can do it.

Small price to pay for avoiding the web of arbitrary policies when you host elsewhere.

Notes

  1. In the time since I drafted this article, they seem to have retrofitted the shortcode to use the captioned video. I maintain this was embarrassingly late, but I’m happy to see a positive move.

Archive links

Why (not) pdf?

Text Collector lets you print text messages by converting them to pdf. What we call “text messages,” of course, includes messages with both text and pictures. Sometimes they include other types of attachments, like dirty .gif files, but that’s another article. For now, I’m just discussing images and text.

On the surface, pdf seems ideal: it’s universally viewable, supports pagination, and, unlike images, includes text in a searchable way. But I don’t really like pdf as an ediscovery interchange format.

Why? Pdf is too complicated. As file formats go, it’s far from the worst monster out there, but it’s also far from simple. As a consequence, the many different programs that generate pdf often get it slightly wrong; they’re not necessarily bad programs: they’re just dealing with a complicated problem and make mistakes.

Pdf viewers grapple with the resultant problems and show you something that looks correct, so everything seems fine at first.

When you want to edit pdf, however, things quickly go wrong. For a typical ediscovery operation like stamping Bates numbers on your pdf files, the small errors compound and you have a significant chance that the result will be illegibly damaged.

Assume some set of pdf files P , and an operation b that you want to do on them to produce an output set, O .

b:P \rightarrow O

You can visually check some number v for correctness.

When the size of O is larger than v there will be some subset E, larger than zero, that is terribly broken.

E \subset O \land |O| > v \Rightarrow |E| > 0

Ulfers’ Law of Batch Pdf Editing

Second, since it is complex, pdf allows all manner of invisible content. This makes redacting pdf hazardous and if you have a highly-developed sense of self-doubt, it’s hard to shake the feeling you’ve done something wrong that allows the redaction to be removed.

So, why does Text Collector convert messages to pdf and not something else?

There are no suitable alternatives. Html is universally viewable but has no notion of pagination and very limited image embedding. Microsoft Word format is too easy to edit, and comparable in complexity to pdf. Mhtml never got universal support and it lacks pagination anyway. Tiffs and text are too large and useless to average people. How about svg?

So pdf it is, for better or worse.

Print text messages: video edition

Today I published my first YouTube video, How to print text messages on Android:

I already knew the obvious choices of software to use for some elements: Audacity to record and edit narration, Pixly to draw the hand pointer animation. I’m a novice at making videos, however, so I spent a good deal of time figuring out what program I should use to edit the video.

First, I tried Kdenlive, and managed to put together the entire video how I wanted it, only to run into a fatal error: I couldn’t export successfully.

Eagle-eyed viewers may notice that the part where I demonstrate a purchase doesn’t use an actual currency. There are actually several layers of compositing in this shot:

Purchase screen with generic currency symbol

When Kdenlive attempted to render this, it just produced glitches: it flashed images like the sad face emoji, from completely unrelated parts of the video. No settings tweak I found solved the problem.

So, on to OpenShot, whose interface feels largely comparable to Kdenlive. I soon discovered, however, that it lacked some basic effects that I needed, particularly freeze frame. Apparently version 2 lost a number of effects that were present in version 1.

Finally, I moved to Blender. I guess, deep down, I always suspected it would come to this.

Blender is a ridiculously capable program, especially when you consider how lightweight it is. It manages to include 3D modeling, rigging, rendering, animation, compositing, video editing, a game engine and more in a download between 80 to 150 megabytes, depending on your operating system. Compare to, say Maya, which can take days to download.

How Blender accomplishes this is surely black magic, but it’s not for fear of the dark side that I avoided it till last: it’s the user interface. To the uninitiated, Blender feels like learning how to use a computer for the first time.

Want to select something in the timeline, or, in Blender-speak, the “video sequence editor?” It’s right-click, not left-click. Want to move it? You can click and drag, but it won’t release when you let up on the mouse button. You need to click again to release. Scroll wheel zooms. Ctrl+scroll wheel scrolls. And so on.

In other words, Blender’s interface is comparable to Dwarf Fortress.

Nonetheless, it only took me about day and a half to re-cut my video in Blender. On the bright side, if I ever need to add a 3D Text Collector mascot and some explosions, I’ll already be in the right program.

Text Collector version one released

Today, Legal Text Collector graduated from beta to production, version 1.0. It’s been a long time coming: I started working on it seven months ago. I made my first notes on the idea about five years ago.

Exactly thirty years ago today, Reagan said, “open this gate. Mr. Gorbachev, tear down this wall,” and in a small way, I think I can sympathize with Gorbachev. The main change from beta to production is that now people can start posting reviews: I’m opening the gates of public criticism.

Google allows public reviews only after a production release. In the safety of beta, Google provides a private feedback option, which nobody used. Many people did, however, send me questions and bug reports via email.

It’s hard to overstate the the value of that feedback. My friend Trish, my aunt Meg and my erstwhile colleague Jon of Sandline were especially helpful in testing the early alpha versions; strangers who stumbled upon later public betas kindly sent me information to resolve some of the final bugs. Through 14 alphas and 16 betas, Text Collector grew from 3.5 thousand lines to 5.5 thousand, a testament to how long the long tail can be.

So it is a dramatic moment. Much remains to do, but at some point I must tear down the wall to public criticism. Private feedback has been overwhelmingly positive, so this doesn’t worry me too much, but only time will tell.

It’s a good day to print text messages

Even though my elevator pitch for Legal Text Collector is, “It lets you print your text messages,” in all the time that I’ve been writing it, I never actually printed any messages.

Text Collector doesn’t (yet) print text messages directly. Instead, it converts them to pdf, and you’re free to copy and print pdf as you please. In development, I just examined output pdf. Many, many times. Printing is a formality.

Still, this gives me an itchy feeling. I find it unsatisfying to leave the final step untried.

So I celebrated the beta 15 release by actually printing messages. On paper. In color and grayscale.

Why celebrate beta 15? I expect it to be the last beta release before 1.0. Every 1.0 feature is in and every 1.0 bug is fixed. In other words, beta 15 is Version One. All that remains is to take a deep breath and bless it with a “production” designation.

 

Where have my emoji gone?

Bob, what were your six biggest challenges in developing pdf?

Dave, that’s easy. Fonts, fonts, fonts, fonts, fonts and fonts. In that order.

The most noticeable limitation of Text Collector is that when it converts your text messages to pdf, it drops emoticons. Instead of smiley faces, it displays diamond-question mark things, “replacement characters.”

As ever, fonts are the problem.

When you need to display something laid out just so, such that it prints on a page and everything fits correctly, text alone isn’t enough.

Text, nowadays, usually means some encoding of Unicode. Technically, it’s a “Unicode transformation format,” which is where we get the “utf” in utf-8. Impress your friends and family with that.

Unicode represents abstract concepts, like the idea of the letter A or a smile. Emoji, just like letters A through Z are Unicode text, but precisely how letter A or winky face actually gets written to the page depends on your font.

A A

If you want to ensure that your text fits on the page, doesn’t run over or under the things around it, or, indeed displays at all, you must also include a font. In pdf terms, this is called “font embedding,” and it is what Android’s built-in pdf library does.

So far so good: just embed the emoji font and smiles or piles of poo come along for free, right? Wrong.

Most fonts specify letter outlines and leave color of the letters up to the user. Thus, I can say that I want letter A in blue or orange and both are the same font:

A A

Not so, Google’s emoji font. It includes cats, dragons and piles of poo in glorious, and heavyweight, color. Including this font makes for a massive pdf: almost 10 megabytes, on Android 6. It only takes two or three such documents to blow past Gmail’s attachment size limit. Typical collections would run into hundreds of megabytes, or gigabytes. They could easily consume all available space on the device.

This isn’t a new problem, and there’s a well-known solution: font subsetting. That is, only include glyphs for the small handful of characters that you actually use. Android’s built-in pdf library can’t do that.

So, to get emoji, I have to bring in an entirely new pdf library… and I’ve been working on this long enough. Version 1 needs to ship. Emoji will have to wait till version 2.

Why Android threading isn’t good enough

Text Collector exports your text messages organized by conversation. Conversations – also known as message threads or strings – are crucial to understanding the context of text messages. If Text Collector did something more naive: put every message in one big document according to date, perhaps, some messages would find themselves incomprehensibly woven together with other unrelated messages.

Apps on Android access messages through “content providers,” and since Android does include a content provider that lists messages according to conversation, the easy way to get message threads is to ask that provider. It’s not what Text Collector does.

The trouble with Android’s threading implementation is that it allows a message to be part of one, and only one, thread.

Android’s design is sensible enough when there are only two people on a conversation. In that case, messages intuitively belong to just one thread. Suppose Alice is having a conversation with Bob, and separate conversation with Charlie: she simply has two threads, one for Charlie, the other for Bob.

A more nuanced way of looking at message threads might also divide messages by topic. In email, for example, threads can be based on the subject line. For text messages however, a simple categorization by recipients is more intuitive.

Eventually, Alice finds herself discussing the same topic with both her friends, so she copies Bob and Charlie on a message that says, “Hey Bob, Charlie says you’re wrong.” This group message has to go into a thread, but Android doesn’t know whether to put it in the Bob thread or the Charlie thread. And lo, Android creates a third thread.

Intuitively, the group message actually continues both conversations, but since Android can only give it one thread identifier, it can’t represent that. People can join conversations, leave conversations and have related conversations on the side, but Android’s threading model represents none of this.

While using the phone, these broken threads aren’t too confusing, because you read the messages with context still fresh in your mind. They can be very confusing, however, when reading messages long after they were sent. If Text Collector used Android’s threading model, you would often need to cross-reference several documents to understand where messages really belong.

Instead, Text Collector puts the message in both the Bob document and the Charlie document. There’s a bit more to it, but if you want gory details, check the website.

No matter which document you read, Text Collector’s threading strategy makes the whole conversation understandable, and it has another happy effect for legal review: all Bob messages appear in a single document, and same for Charlie. Thus, in the common case where you want to collect Alice’s messages and review everything she discussed with Bob, you don’t have to worry that they might be scattered across a mess of different files.

Mind you, this is not magic. If Bob does something tricky, like change phone numbers, Text Collector won’t know about it.

Build one to throw away

Most software projects inadvertently plan to build a throwaway product for delivery to customers, instead of heeding Fred Brooks:

In most projects, the first system built is barely usable…

Plan one to throw away; you will, anyhow.

Luckily, when building Text Collector, only my own management expectations burdened me, so I had an opportunity to build a real pilot and chuck it.

I wrote the pilot in Java and it included all the major features I knew I would need. Thanks to Steve Yegg popping up for the first time in a few years, I heard about Kotlin, so I switched to Kotlin for the real program.

Now that it’s in alpha, I can reasonably compare the size of the two programs:

Java Kotlin
Lines  1.9k  3.5k
Words 6k  13k
Bytes 71k  146k

By many standards, this is small, and smaller yet when you consider that I’ve counted using simply the “wc” command, so the numbers include whitespace and comments.

The pilot included all major functionality, but ignored most edge cases. It featured mms and sms collection with:

  • Date filtering
  • Message preview (small collections only)
  • Pdf creation
  • Pdf sharing
  • Inline image rendering (no scaling)
  • Zooming (without panning or clamping)

For the real program, I kept all the pilot features except contact filtering, added handling for many edge cases, and added features:

  • Organization by conversation
  • Zip creation
  • Reporting usage statistics and errors
  • Failure diagnostics and debug features
  • Option to cancel collections in progress
  • Pre-calculated layout (allows preview for large collection)

So, the Kotlin app has roughly twice the features, with roughly twice the amount of code. At first glance, it doesn’t seem like that significant a difference, but breaking it down this way lets me count up the lines associated with new features only: 1.3 thousand. Thus, the part roughly equivalent to the pilot weighs in at 2.2k lines of Kotlin to Java’s 1.9.

In other words, Kotlin, handling edge cases, is only 15% larger than the equivalent Java that ignores edge cases with wild abandon.

My commit log shows that the Java version took about one month, while the Kotlin version took three. That seems pretty dismal: two thousand lines per month in Java and closer to one thousand in Kotlin, but…

The Java pilot had no tests, the real, Kotlin version adds 6.6 thousand lines worth of test code.