Posted on

Epub Editing Tools

Tools change over time, but it seems that in the Epub world we have more of the same. As of November 2018: - Calibre's Epub Editor is pretty nifty - Sigil development stalled, then picked up again - Pagina Epub Checker is still under development and useful - Pandoc with or without some kind of TeX, LaTeX, or XeLaTeX -- the last one is better for font support Things haven't really changed over the past X years, much. Certainly not since the 2017 note on Epub tools.

Some Pandoc Resources

Posted on

Podcast Platforms

Podcasting is growing (slowly) and offers a great opportunity for brand engagement. Generally free, the idea is to be where the audience already is, and have a reliable host for content and the rss feed.

Media and RSS Hosting

Google Podcasts and Google Play Music Podcasts

Note, these are two different things: First Thing - Google Podcast (part of Google Search) - Google Podcast Publisher Tools - Google Podcasts App Second Thing - Google Play Music Podcasts

Pocket Casts (#4 platform

Stitcher (#3 platform)

Spotify (#2 platform)

iTunes/Apple Music (#1 platform)

WordPress Plugins

Posted on

Telegram for Social Networking

Telegram is a great chat app, but there is more, and less to it, than say Twitter and Facebook. The first thing is that a lot of this gamification of likes/thumbsup is gone. Want to know if someone read your post? That has to be done either via direct message, or in a group (and the person has to respond). Recently there are new apis that help enable discussions on posts, as well as connecting channel posts as annoucements in groups.

Types of Accounts in Telegram

There is a single namespace in telegram for all entities: users, channels, groups, and bots. Users are individual accounts tied to a phone number (I think that is mandatory). Telegram Channels are one-way broadcast accounts, which can have multiple admins (but messages are signed by the channel. Membership in channels is unlimited. Telegram Groups can include up to 200,000 users, and everyone can post.

Using Bots for Commenting and Discussion

Note that for feedback on channel posts one can add a like bot or other such simple feedback, or add a discussion group and put that information in the channel description. A third new option is to have a comment system using an app which would also be available on the web as a preview (without logging into Telegram). The preview bot that does this works nicely and shows off what kind of api/developer support Telegram.

No Manipulation or Advertising

Instead of the constant intrusion of 99% annoyance in terms of timeline distortion and advertising as found in Facebook and Instagram (and to some extent Twitter, which is going down that same path).

Essentially, the use of channels with comments can replace any given social network (other limitations apply), such as Twitter, Facebook, and Instagram. While those platforms still have the lion's share of engagement and users, moving over to the Telegram way of things makes sense.

Telegra.ph for Longform

Telegra.ph is a longform microblog platform which is very simple and also has zero advertising. There is a nice Telegraph App in the Google Play store.

Installing Telegram

For the Linux and ChromeOS world, the options are: Telegram Desktop (for Linux) and Telegram Android App (for ChromeOS).

Posted on

Inkscape – Open Source Vector Graphics

Inkscape is an amazing vector graphics editor. It is free and open source and works on a variety of platforms, including Linux, Windows and OSX. Inkscape replaces Corel Draw and Adobe Illustrator and can read their files, and is a first class citizen among these other editors. > This page will be semi-regularly updated to put my own Inkscape experiences into words. Last updated 19-Mar-2019.

Inkscape on Linux (Debian)

Install Inkscape from flakpak:

sudo apt install flatpak -y
sudo flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo
sudo flatpak install flathub org.inkscape.Inkscape
sudo flatpak update -y

Adjust the shortcut to run flatpak run org.inkscape.Inkscape

Inkscape on OSX

Unfortunately the mainstream OSX release runs on xQuartz which is slow and doesn't support the standard OSX keystrokes and menus. Plus the windowing is not flexible enough. The main branch has continued development while the idea is to get a native release working with Gtk 3, but it is unclear if or when that will take place. For years I have used an old 2013 release from Valerio Aimale. There is now a 2017 release for Inkscape 0.92.2 but it doesn't run on OSX 10.01 (Yosemite), so I am unable to test or use. While s_uv is working on a next version of OSX with Gtk integration (called OSX Menu), it still is wrapped in xQuartz, with the same issues. As of mid-2018 I no longer use OSX, so things may have changed since then.

Inkscape Features and Functionality

  • Inkscape Keyboard and Mouse Reference I use Inkscape as a drawing and illustrating tool and also for editing images in terms of compilations, extraction and svg-ification, logos, book covers, basically everything under the sun. As with any tool, getting efficient with Inkscape is a discovery process with a learning curve. As well, I happen upon a variety of features that continue to amaze, including:
  • Barcode generation: > Extensions > Render > Bar Code
  • etc. Inkscape supports extensions including:
  • Inkscape Map Inkscape SVG files to HTML image map or coordinate list
  • Inkscape Table Support
  • Etc.
Posted on

Grav CMS on Debian

This post will be frequently (or infrequently) updated. It is meant to help me learn Grav and Gravcart, and in particular migrate off of WordPress and Woocommerce.

Related Artices in Debian Services and Applications - Debian on AWS Lightsail - OpenVPN on Debian + UFW Firewall - Nginx and Letsencrypt on Debian - PHP & MariaDB on Debian

- Grav CMS on Debian

Grav, Gravcart vs. WordPress, Woo

WordPress and Woocommerce have such overhead, including dependencies such as MySQL, that it is important to seek out a functional but higher performing option to manage modern websites and web storefronts.

Installing and Configuring Grav

The best approach is to download the Grav + Admin zip file, unzip and move contents to the webroot. I've had issues with using github and composer, so the zip file is a less problematic place to start. ... details to come ... Finally run bin/grav install to get plugin and theme dependencies

bin/grav install

File Rights

I've found that permissions get jammed every now and then. Overwriting them with a script is the easiest approach, as follows:

chown -R www-data:www-data /var/www/WEBROOT
find /var/www/WEBROOT -type d -exec chmod 2775 {} \;
find /var/www/WEBROOT -type d -exec chmod g+s {} \;
find /var/www/WEBROOT -type f -exec chmod 0664 {} \;
find /var/www/WEBROOT/bin -type f -exec chmod 0755 {} \;

Resources for Grav and Gravcart

Posted on

Caret vs. Caret – A Tale of Two Editors

Caret the Chrome App vs. Caret the PC App -- not sure which came first, but they are very different (except for the name, and the fact they are open source).

Caret the Chrome App

Note that Caret may possibly replace Atom in my workflow - Caret in the Chrome Store - Caret website - Caret source on Github - Caret wiki on Github

Caret the PC App (Linux, OSX, Windows)

Note that while Caret the Chrome App may possibly replace Atom, Caret the PC App has some great built in Markdown display (it is Markdown-focused rather than general-text-editor-focused). - Caret.io website - Caret on Github - Caret wiki on Github - Caret on Twitter

Posted on

MediaWiki vs. WordPress

There of course is no MediaWiki vs. WordPress in the sense of a battle. As Wiki and Blog platforms go, each is the winner in their category in terms of raw number of users/pageviews. That said, there are definitely (different) concerns with each platform, architecturally as well as accidentally. And therefore, we dreg up the battle metaphor. To the fighting pits!

Markdown vs. Wikitext

Markdown isn't the default in WordPress, indeed there is way too much emphasis on the visual editor. That said, Markdown is common and available via plugins, and shortcode functionality is also prevalent. For MediaWiki, the wikitext markup remains dominant, to the exclusing of Markdown. But no where else than MediaWiki is wikitext deployed.

Namespaces and Transclusion

MediaWiki namespaces are ways of organizing kinds of documents (sometimes without much real effect other than naming), as well as allowing for transclusions and templates. For WordPress templates, or better custom post types, are monolithic and govern an entire page of a certain kind (for example, products). While custom posts and templates are distinct, and there can be more than one template for a given custom post type, they essentially are managed as an area for programming, vs. the looser, and easier to edit templates (powered by WikiMedia transclusion extensions), so that moderately capable editors can customize the look and feel of pages without needing administrative access. This gives MediaWiki a more democratic and flexible system, that however ends up creating an additional level of administrative editing work. I've you've got millions of editors, this is fine, and necessary, but if not, it becomes more difficult to manage.

Caching Techniques

MediaWiki has some built-in caching, and for WordPress this is the domain of plugins. Still, these sit on top of PHP, MySQL, and Apache, so the caching strategy is the same.

Themes and Skins

Themes in WordPress are where the look and feel, layout and design live, while for MediWiki these are skins. As with most things CSS (and a little javascript), the customization can be extensive. The trouble with skins, besides the fact that most are very ugly, is that the paradigm of the Wikipedia page generally dominates. Wikiwand has gone far to beat back that design, and done so effectively.

Templates, Templates, Templates

Templates tend to grow like mushrooms. For example this page has 53 templates. There are mainly just a few template types: - Page or fragment formatting templates - Info-box style templates - Weird parsing or inclusion templates From an architecture perspective, this is obviously nuts (a technical term). First off, getting down to the root of it, there should be widgets, templates, and plugins. While certainly it is convenient that this is the WordPress model, the reality is that not managing these issues site-wide is a recipe for disaster. One ends up with... 53 templates. Bartleby the Scrivener, indeed.

Javascript and CSS

For WordPress, including javascript and css is generally straightforward, and there are plugins such as the masterful HeadSpace which makes insertion of includes straightforward. In comparison, MediaWiki's approach doesn't always work very well. There are the common files, but adding includes is not obvious. Wikia documentation helps out (but again, is incomplate). Technical documentation of MediaWiki is by far the weakest and most troubling part of the distribution. Technical documentation is either non-existent, incomplete, or out of date -- usually a combination of all three.

MediaWiki and WordPress - Deep in Technical Debt

The attempts to make sane improvements to MediaWiki and WordPress (and most recently, WooCommerce) have exposed an enormous amount of technical debt. MediaWiki makes mention of this, but their attempts to address this are essentially don't touch what we can wait to touch later. WooCommerce 3.0, in less than a month, has released six bug-fix patches, having broken a huge amount of their customer base. The insanity continues on WordPress releases, which no longer have timelines (only some kind of undefined feature release rationale).

A Revisit for Sanity

Both MediaWiki and WordPress have extremely poor core technology stack, and while it can be made to work and scale, the process is generally painful. In addition, with core version control distributed collaborative editing and website display, there are few reasons not to build something that can fix both of these problems, provided the core functionality of both applications is built first, and the architecture is thought out better. This should fix speed issues and caching issues.

Challengers and Replacements

Because part of the issue has to do with the database requirements, flat file systems have a distinct advantage. Additionally, active, full-featured projects that are able to do some kind of migration/import, are a strong consideration. Two in particular are: - WordPress / Woocommerce --> Grav / Gravcart - Mediawiki --> Dokuwiki

Posted on

Scribus – Open Source Adobe Indesign

Scribus - Open Source Adobe Indesign Scribus is a maturing publishing tool which has much to like. The upcoming (when? who knows?) release of 1.6 should put it squarely in direct competition with Adobe Indesign, it's proprietary competitor. Scribus is free and open source software, developed with love. However, there is one bad part which is the development lead who believes that new versions (e.g., 1.6) should be released over several years, rather than several months. Too slow for my tastes, though they are doing incremental releases at a faster rate, and frankly it is a nice piece of 'ware. > Note, my own use of Scribus fell down with several issues, including this bug that may not be around anymore, and I've gone back to an older approach using Inkscape for vector graphics and Markdown, Pandoc, and XeLaTeX (XeTeX + LaTeX, which handles unicode fonts and is the only real solution for non-latin script support) to generate epub and pdf programmatically. Scribus is basically damned awesome and should be tried out. It is the future (and possibly current) replacement to Adobe Indesign. Along with GIMP, Inkscape and Blender, Adobe can be retired (and I personally have not used any of their software since 2010 (and any Microsoft software since 2007). Continue reading Scribus – Open Source Adobe Indesign

Posted on

Screen Promiscuous – Publishing

Yes, screen promiscuous, a term I did not know before reading the piece on Snowpiercer in the LA Times.

Short and Longform Trends

As John Borthwick reports there are two trends in media consumption seemingly at odds, lots of micro/immediate shortform content being consumed and reflected, as well as longform, quality content that has significant time needs to interact with (and getting that time share). It is important to understand that shortform can be understand as the mere headlines of medium or longform content (and that there are some serious problems with the fact that much sharing on social media is not even consumed or digested by the sharer previous to sharing/re-sharing).

Screen Promiscuity

And so, to jump ahead (if you missed the point, go back and read what I cited) what we see is indeed across-the board screen promiscuity (yes, old print books still exist and are also seeing at least stable consumption as well). We are in the great age of content (be it poor or great, short or long, and no, the two are not diametric poles). Indeed, there is much longform which is atrocious.

Death of Middle Content

Like Middle Earth, a place of creeping doom, the middle place of content -- middling in length, middling in focus, middling in quality -- is a place of death. Better just go for a ...and you will never guess what happened next, top 11 slide-formatted listicles, click-clickety-click-click mindlessness, or really sit down to create that evergreen, canonical content with a laser target and fantastic asides.

Distribution, Distribution, Distribution

Now back to this screen promiscuity, which really means distribution, and a need (because of the impressive increase in engagement, or at least presence on these screens) to be available whenever and wherever someone wishes to engage. Longform on a mobile device? Believe it. Shortform on 23 inch monitors, every day in every way.

Feature Film is the new POD

We should call it DOD -- Distribute on Demand -- instead of POD -- Print on Demand, for it is really the ebook revolution in some senses. Sure, we've already had much of this with iTunes, Amazon, Netflix, not to mention dozens of other on-demand or small-device platforms for video-on-demand. VOD by itself just means streaming asynchronously from a library rather than broadcast. However DOD is more than that, as what is disrupted is not only the mechanism/timeshifting for consumption (again, screen promiscuity) but the fact that distribution networks are being disrupted and there are other options beyond traditional gatekeepers and ticketpunchers. Here are some distribution points of interest: - Snowpiercer and the future of distribution (cited above) - Offer your movie everywhere - VHX blog - The Act of Killing - Bittorrent Bundle reaches 3.5 million downloads So the point is to leverage screen promiscuity. It is working for The Atlantic, Medium, The New York Times, Guardian and Slate, to a significant degree. Be everywhere, in social media with a (come on, at least reasonable) headline, and in other distribution channels for free and for sale.

Posted on

Life is a kind of Library

A famous writer (Borges) once said that he imagined the afterlife (or more precisely Paradise) to be a kind of library. However, what occurs to me now (in at once a banal and deeply moving way) is that not only the afterlife, but Life is a kind of Library. I mean this both as metaphor and allegory, but also as a framework which helps clarify certain things, such as information management, complexity theory, search engines, marketing, and other such avocations and vocational pursuits (including how to think about people's behavior). > I have always imagined that Paradise will be a kind of library. -Jorge Luis Borges Life is a kind of Library Continue reading Life is a kind of Library