dustin1114

There is a bit of manual tweaking required in LaTeX that I haven't figured out how to automate yet. It's mainly related to chapter endings: if there are only 2 or 3 lines on the last page, I can subtly tighten the tracking from a paragraph on the second to last page and eliminate an almost-empty page. Also, I have PNG maps that currently need some one-off LaTeX directives to lay them out how I want. I could probably embed some properties in the ODT image, but that seems kind of janky. If I needed to regenerate from the ODT source, I use a Git three-way merge to update it (also janky, but it's expedient).

Last I checked, typst doesn't have baseline grid support (i.e., assures vertical lines of text across spreads are aligned, thus text doesn't bleed through recto to verso).

Asciidoctor was in the running months ago. I like the idea of a single set of files, but yes, word processors are my weakness.

typst is great. I experimented with it, it I simply didn't have the fine-tuning and maturity LaTeX. For example, window/orphan control is a binary on/off, while LaTeX calculates by penalties at a much lower level. Pandoc is also great (I used it often for unrelated workflows), but it can't map custom styles from ODT files (not sure about Word).

I use VS Code soft-wrapping, and `git diff --word-diff` does all I need, though there probably are better methods.

Author here. You're exactly right. All of my pre-grad education was liberal arts. I had never once heard of LaTeX until I entered the software world years later, and even then only from a coworker with a CS PhD.

Author here. Yes, I wrote the books and glued everything together. If I failed to mention it in the article, it's because I was trying not to self-promote so much. Thanks for the compliment. It really was fun to figure it all out, if that wasn't clear :)

This was an early inspiration for me that I failed to mention in the article. I'm glad you mentioned it. It really does have a lot of good examples, especially the complex lists and diagrams it implements in TeX.

I saw typst in my explorations but LaTeX had a few more of the controls I was looking for in print, and I really wanted a Standard Ebooks compliant EPUB. I might revisit at some time though. Thanks for bringing it up.

Yes! All the typographical techniques and terminology is fascinating (and confusing at times). Widow and orphan control really fight against text justification. Finding the right balance is tricky, but LaTeX has all the little knobs to tweak and find what's right for your uses (fiction for me).

Hi, OP here. I'm glad you enjoyed the writeup.

Amateur...you're probably right. It reminds me of my home improvement project I've been working on this evening: interior painting. My ceiling lines are probably perfect to houseguests (if they notice at all). But if a professional painter got up on a ladder and looked closely, he'd probably shake his head and chuckle.

As for InDesign and EPUB, I've found the auto-generated output not up to the standard I was after. Worse, I've seen output differ between InDesign versions, which scared me.

I have an acquaintance who works for a "Big 5" publisher, and he recounted their process to me once. In short, the indd file became the source of truth. They would generate an EPUB from it but then hand edit it for many hours to bring it up to their house style. If there was a text change (rare in fiction) they update the indd and EPUB separately. Going back to the Word file is basically non-existent. If the author, copyeditor, proofreader had more extensive changes (like a full revision), it was close to a brand new publication.

The visual styling from the word processer isn't interesting. It's the "tagging" that paragraph and character styles bring that's helpful. It's not dissimilar from an HTML class, which scripting can transform into truly semantic text. I hope that clarifies some points. BTW, it's pretty cool to hear from people in the real print industry. I'm always fascinated by their workflows.

I wrote a relatively simple web application (https://github.com/DSpeckhals/bible.rs) about 9 months ago with version 0.7. The initial code changes to migrate to 1.0 weren't that bad (https://github.com/DSpeckhals/bible.rs/commit/fbd7e8207023a0...). The most substantial changes I made during the migration weren't necessary, but according to the author, are a little more idiomatic actix-web: moving from sync arbiter actors for Diesel connections to just using `web::block`. Both use a threadpool behind the scenes, but `web::block` is less verbose.

I've been extremely satisfied with its performance and ergonomic abstractions over HTTP and async Rust that actix-web offers. And like others have mentioned, the author and other contributors provided me with some good, practical answers to a few questions I had.

The Java (5+) Map interface can be typed using generics (which -- if JS eventually introduces static typing -- I hope is implemented).

  Map<String, Integer> = new HashMap<String, Integer>();

That declares a Map with a String key and Integer value. Is this what you're thinking of?

It's kind of funny. ES6 seems to be making JS more "Python", while "strong mode" makes it more like Java/C# (at least to me). I'm open to worthwhile changes; I'm just thinking about the tens of thousands of lines of JS I've written with various utilities and libraries, and how they will eventually fit into ES6...I'm not too sure about strong mode, though. I guess we'll see how it all pans out.

Agreed. And unless I'm reading the document wrong, this would also be prohibited in strong mode:

  let x = {
    keyA: "valueA"
  };
  x.keyB = "valueB";

I think I like most of what this document proposes except for the following:

  In strong code, accessing objects (strong or not) throws on missing properties.
  New object properties have to be defined explicitly and cannot be removed
  from strong objects.

To me, this seems to break a fundamental aspect of the language. I've found it very acceptable to be able to define an object literal property "on the fly." However, with strong mode trying to make the language friendlier to eventually being more statically typed, I see the necessity. It just boggles my dynamically typed mind :-)

Disclaimer: I'm a son of the Midwest :-)

This article hit home for me. Though I technically now live in a medium-sized mid-Atlantic city, the culture here is more like the Midwest. I'm not against the Bay area or NYC, but for me, I couldn't imagine living in those places: congestion, price of living, and their lacking of the "down-home" feeling.

I believe it would be more difficult to found a technology-centric company where I live, though. As an example, the company I work for, though very large, is based in a small city. For years, there was not much of an issue attracting new talent. The problem is that our IT organization has grown immensely recently, and attracting new "hacker" talent into the middle of the country is a huge obstacle. One of the solutions was opening another IT office in New Jersey, just a few miles from NYC. Problem solved.

But then there's those of us who grew up in the Midwest. I love being able to buy and own a nice home for under $200K. I enjoy being able to drive to work with minimal traffic. I even like reading about living in the Bay area on HN and laughing at the things so many have to deal with! But the truth is, tech people thrive in the Bay area. And I'd say that the Bay thrives on them. But there will always be a few of us engineers who live in "flyover" country :-)

I like the idea of a WP API. I guess in the future you could more easily build non-browser apps that utilize WP data. Of course, there's always going to be the people who don't very much like the whole front-end JavaScript MVC idea (Backbone, React, Angular, etc.), but there will still be the regular PHP themes for them to use.

My only wish is that a proliferation of horrible themes based on inefficient JS does not occur. Front-end MVC can be done right, but don't abuse it with bad code that gives the rest a bad name!

In regards to "circumstances", I was specifically referring to the gridlock in Congress (since we're posting links, here's one: http://blog.oup.com/2013/10/federalist-papers-government-gri...), not gerrymandering; which is prevalent in heavily GOP and heavily Dem states. I think gerrymandering is a little off-topic here, so I'll defer for now :-)

The truth is, I think we might agree more than you think. The problem with the last thirty or so years in politics is that politicians (and by default, those they appoint) and special interest groups (corporations, labor unions, etc.) have created together what's we often referred to as "crony capitalism." Do you really think that the FCC and the current administration are doing this "for the people?" No, they're pandering to the tech block (Google, Facebook, eBay, etc.). I don't see that is being too much different than pandering to the big ISP's.

Capitalism without a sense of morality will itself turn into an oligarchy, as we see now. Thus, people seek more government regulation, which then just breeds more interference in individual freedoms.

I agree, it is national communications policy. But why not try getting a new statute passed that isn't based on telephones from the switch-operator era? It just seems to me that it's being pressed so hard because it's such a "fad" issue right now. Most people honestly don't even have a clue what the FCC or "net neutrality" is. Sure, the FCC is accountable to the President (ultimately), and to congressional oversight committees, but they don't have to worry about being thrown out of office for any decisions they make.

These circumstances have been happening since the creation of the United States. We act like things move far slower now than they ever have. The government was made to move slow on controversial issues.

Still, the closest thing we have to a democracy is not the FCC, it is our local/state/federal election process. Sure, there's money involved -- too much in fact. Push your representatives, they might listen if enough people let them know. There are turnovers in seats every two years on both sides of the aisle because of their bad decisions.

It seems to just be more federal regulation from DC. I'm as much of a fan of a free and open internet as anyone, but why risk the FCC getting involved?

Also, can anyone honestly see rates being reduced because of this? Sure, all of us would love to see more competition (I actually only have one choice where I live, sadly), but the truth is, the companies that invest the capital to build the infrastructure deserve to reap the profits. I'm not quite sure what the solution would be to having more competition.

What worries me the most is the bureaucracy of it. Are we the people really getting a say? The FCC is made up of unelected officials (appointed by the Executive branch, Republican or Democrat) plastering on their views. Why not let our elected representatives take care of this? You may say that they would just block it, it would never move, etc. Perhaps it's not as much of an emergency as we think, then? I guess this is just the same old federalism versus statism argument. Good ol' American politics.

I code for the thrill and pleasure of the creativity involved. As an add-on, it provides for my family.

You could try CoffeeScript. It takes away a lot of what people don't like about JavaScript out, and replaces it with a decent syntax. I personally love well written vanilla JavaScript, but CoffeeScript might give you a little better experience if you "hate" JS.

So, is it the DOM you don't like, or the actual JS syntax and structure? For me, when I overcame the weakness of the DOM API, and utilized it elegently, I started to enjoy JS.

After hearing about the idea of a phone from Amazon, I really thought they'd do more. I like to buy things from Amazon (like many here probably do), and thought that the phone would be competitively priced. It wasn't in my mind; and with only one major US carrier (AT&T) that it's being sold under, the customer base is even smaller. I love the ability of my current unlocked Nexus 4 to switch to another carrier or MVNO. Call me spoiled on the Nexus devices...

How would I be sold on the Fire Phone, Amazon? Allow the phone to be unlocked and lower off-contract price. Then, I'd consider it. I like the phone's features, but if the value isn't there, then I'll pass.

It was refreshing to see something like this on HN. I'll have to look into it. Thanks!

That's pretty neat: I discuss an interesting subject with someone on Hacker News that directly affects my current industry, but I am a few levels down in the supply chain. I deal more with product distribution and logistics, while you deal with the actual manufacturing of the pallets they sit on. Thank you for your expertise and insight!

I have no disagreement with you on the merits of both CHEP and GMA pallets. I have have experienced good and bad pallets of both types, and the cost is definitely the deciding factor in the equation.

Generally, these are the pros and cons I see with the major types of pallets:

Pros ==== GMA: inexpensive, standard, lightweight (a VERY big deal when cubing out a truck), easy on the supply chain.

CHEP: pretty consistent, longer lifespan

iGPS: very consistent, easy on automation, they feel indestructible

Cons ==== GMA: generally a shorter lifespan, inconsistencies between manufacturers, quality varies

CHEP: expensive, heavy, red tape

iGPS: extremely expensive, heavy, red-tape

And yes, depending on the vendor, the quality of GMA pallets varies. There are excellent pallets that hold up and seem to be built with quality material, and there are others that feel like they break into pieces after a few handlings.

I've worked in grocery logistics for several years, and can tell you from experience just how political CHEP, PECO, and iGPS pallet distribution can be. Because of the size of my organization's warehouses, CHEP especially requires stringent audits, and if a truck sent out with CHEP when it was not supposed to, the gestapo comes after you.

I will admit, though, that CHEP are the best when it comes to quality (other than iGPS, perhaps). They are far less likely to have splinter, warp, and degrade. They are also much more resilient to the abuse that the supply chain puts on them.

An important point to remember is automation. The logistics industry is becoming more and more automated. Consistent, high quality pallets are becoming a must. The typical hi-lo is becoming less and less common, while in its place are robotic automated guided vehicles, distribution conveyors, and high-bay storage and retrieval machines. I know from experience how much pain and frustration is caused by broken stringers, splinters, and warped whitewood (in our industry, we call them GMA pallets [Grocery Manufacturers Association]]. Literally days of lost time annually, which can equate to millions of dollars.

I have no real opinion about what the best direction is. You either fork out more up front for the good stuff (with all of its politics), or you just deal with the bad quality and inconsistencies of whitewood.

I have to say, this was a very interesting article...a nice change from Python 2.7 vs. 3.X!

Cool idea. I thought every day wouldn't be as special, so I went for every week. I'm looking forward to seeing some new projects...maybe some to contribute to.