maskros

Well so I glanced at what that project does.

Congratulations, you've managed to "compress" PDF files by rasterizing every page to JPEG, while destroying all the vector and textual information in it.

The resulting PDF is nothing like the input -- it's just a bunch of blurry JPEG images wrapped in a PDF format.

You can't search or copy the text, and trying to print it will just make a blurry mess of the text.

The CSS outline property is (was?) unreliable on Safari. Things like the border-radius don't affect the outline shape -- it's always square even if you to to create some Apple-patented rounded rectangles using border-radius.

Lots of fonts have monospaced numbers, they just need to be enabled! Look for OpenType (TTF and/or OTF) fonts with feature "tnum", and enable it.

For CSS, use font-variant-numeric: tabular-nums.

To backup you should use the `vacuum into` statement. That can be safely run from another process, as it takes a read lock and doesn't block writers when using the WAL mode.

When backing up a SQLite database that is in running use, you should never use `.backup`. That command will restart the backup from scratch every time the database is written to, so if you're backing up a big database with a lot of periodic writes the backup process may never complete.

You can sometimes use the C backup API from the same process that is writing to the database, since the C backup API is aware of writes _from the same process_. It will still have to restart the backup procedure if writes from another process interfere.

There's a spectrum between completely silent and so noisy you can clearly hear it inside a house a hundred meters down the street.

Then you haven't heard electric cars running at low speed or put in reverse. Try to chill near any space where EVs frequent (like near a parking lot or train station with lots of traffic) and it's a constant source of artificial speaker noise:

WHIRR! WHINE! HUM! LOOK AT ME I'M ELECTRIC WITH A BIG SPEAKER! WHINE! WHIRR!

BING, BING, BING, BING, BING! LOOK OUT HERE I COME IN REVERSE! BING! (The Ioniq 5 is a particularly bad offender here ... the reversing bing can be heard multiple blocks away).

I wish EV auto-makers would turn the default warning noise levels their cars emit WAY THE FUCK DOWN because it's seriously annoying! I get not wanting to startle pedestrians, but you don't have to alert the entire neighborhood...

Since this viewer uses MuPDF as the document engine, it should already support EPUB, MOBI, FB2, and XPS document formats.

If it doesn't, it should be a relatively simple task to upgrade the mupdf library to the latest version and recompile Sioyek to get all the file formats supported by mupdf.

You don't even need the symbol. If you want the simplest thing that will work:

    type Velocity = number & { BRAND: "Velocity" }
    type Distance = number & { BRAND: "Distance" }

    var x = 100 as Distance

The embeddings are just a flat array of floating point numbers. Try typed arrays/buffers to read and write the typed arrays directly as BLOB data. Protobuf and JSON and other serialization schemes are way overkill for something that should be as simple as a memcpy.

Autoincrement is usually not needed in SQLite, and adds a lot of overhead to every insertion since it needs to read and update the sqlite_sequence table on every insert.

https://www.sqlite.org/autoinc.html

Or use "VACUUM INTO" to get a backup that is is even faster (and easier) to restore.

Judicious use of git rebase fixes the commit spam issue.

Because astigmatism or other refractive vision errors.

Think about how astigmatism affects vision, then take into account the effect on pupil size based on incoming brightness, and how this affects the depth of field, and you may understand why.

Last time I tried it was impossible to get Chrome on linux to use the system font rendering settings. There's no way to tell Chrome to:

a) Don't hint/grid fit. b) Don't use cleartype color fringing.

That's reason enough to avoid Chrome for me. Compound that with Chrome's low quality image rescaling algorithms (and the absolute boneheadedness of their bug triaging, where any reports about it will invariably get filed under the wrong component and be closed before anyone who can actually understand the problem will look at it) and oh so many SVG rendering quality issues. I really hope Firefox can survive the current leadership and remain a strong alternative for decades more to come.

"\0" is not a valid JSON string escape sequence.

However, "\u0000" is.

You're not the only one, but my configuration is the opposite of yours.

These are the three lines I always use on any vim install.

    let loaded_matchparen = 1

    syntax off

    map ; :

The first two lines are crucial, because I find rainbow colored text and flashing punctuation extremely distracting. If you find monochrome code unreadable, then that's a problem with your formatting style that you can easily fix.

The last line is really handy for not having to hold down shift so much.

If "handle error" in the catch involves rethrowing the error, or another error, or returning an error code from the function, the "finally" block is _still_ executed.

Here's a "fun" example in Javascript:

  function foo() {
    try {
      return 42
    } finally {
      return "boo!"
    }
  }

It's not "I don't want to learn my tools."

It's "I don't want to learn and debug _everybody else who may possible want to build this otherwise portable C program_'s tools."

When those tools change how they do this unportable thing every couple of years in subtle and incompatible ways, which require #ifdef's to handle the different ways those linked against symbols can be accessed, multiplied by dozens of different platforms, then yes, I'm going to compile an 8MB literal.

With horrible hacks in the reference - search for InputElementDiv and InputElementRegExp if you want to read more about it.

It's not so bad in practice, since you only need to look at the previous token to decide whether a / should be parsed as a division or regular expression, once you've excluded the possibility for // and /* comments.

Comments are also why the empty regular expression in JavaScript must be written as /(?:)/

Not all that uncommon, especially in ifdef situations:

  ifdef (something,something)
    rule:
          something specific recipe
  else
    rule:
          common recipe
  endif

It's also not just rules. Variable assignments are also separate from recipes, and can be indented with spaces.

  ifdef (something)
    CFLAGS=something
  else
    CFLAGS=otherthing
  endif

He is referring to input lag: the delay from input to visible change on the monitor. The double buffering and compositor step added by Wayland adds some delay.

You may not personally notice it, or be used to it, but it's always there. Some people are more bothered by input lag than others, and there are so many compounding factors today that make it worse than ever. It's not only the double buffering in graphics subsystems like Wayland. Monitors are also often adding a frame or two delay to bump up their pixel "response times" and reduce ghosting by looking at future frames.

I swear, using Wayland or MacOS or Windows 10 on the fastest hardware today still feels slower and laggier than 10 year old hardware running plain X11 or Windows 7 (with the compositor turned off).

Given the choice between tearing and input lag, I'll take tearing any day.

That's already happened ... just look at how many youtube channels have integrated a "and now let's briefly talk about my sponsors" segment in the middle.

I'm also in the 24fps hater camp.

It's not jitter that bothers me, it's the stop motion effect. It's especially bad with action sequences that have a lot of closeup shots.

This is basically every movie with any sort of action in the past decade or so. If you do closeup shots in on some fast action in 24fps you don't have to worry one bit about choreography, since it'll just be a choppy blurry mess and nobody can tell what's going on anyway.

It's not just extra DNR applied, modern image and video compression formats almost make it a point to erase all detail and texture from images.

For example, compare the WebP and AVIF (VP8/AV1) compression artefacts with JPEG (and MPEG).

With WebP and AVIF all textures and low contrast details tend to be erased or smoothed out, preserving only high contrast parts of the image.

The JPEG image may have some visible ringing and block edge artefacts, but at least the textures and fine details are preserved!

Chrome has crap image rendering. Chrome has sub-par SVG support. Chrome has a host of issues and bugs with media selectors and imagesets not updating dynamically when changing zoom levels.

So no, one must not admit it is "simply the best engine out there". Not by a long shot.

Not true.

Firefox is vastly better in terms of rendering quality for scaled and/or transformed raster images. Chrome always sacrifices quality for performance, with no way to choose.

Firefox's SVG support is also miles ahead, both in rendering quality and features.

It can be done with relative ease. There is a commercial tool somewhere that does it, because I've run across many PDF files that use a DjVu like structure for scanned books.

It won't be perfectly lossless, because the IW44 compression of the color layer will need to be recompressed as JPEG or JPEG2000. The JB2 mask layer can be losslessly recompressed as JBIG2 or CCITT G4 Fax.

Or maybe we can just have interoperability and open systems so all users can be happy, and don't have to choose between being obnoxious social outcasts or bow down in total obedience to the surveillance capitalists?

This is nice!

I can't help but wonder why everyone still names their API functions Foo_to_Bar when the reverse Bar_from_Foo is so much more readable when chaining conversions.

Compare the example here:

  let myoklch =
    OKLab_to_OKLCH(XYZ_to_OKLab(D65_to_D50(lin_ProPhoto_to_XYZ(lin_ProPhoto(mycolor)))))

With what it could have been if it had used Bar_from_Foo naming instead:

  let myoklch =
    OKLCH_from_OKLab(OKLab_from_XYZ(D50_from_D65(XYZ_from_linProPhoto(lin_ProPhoto(mycolor)))))

libxml2 can be massive overkill if you just want to parse XML data. Unless you need schema validation and namespaces and all that jazz, you can parse XML in C with a simple state machine of ~200 lines. Add another 200 to build a DOM-like structure.

https://github.com/ccxvii/snippets/blob/master/xml.c#L326

Or in lua with ~200 lines altogether:

https://github.com/ccxvii/snippets/blob/master/xml.lua