Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

lsix: ls for images

github.com

Post reply on HN
Print view View original

61–70 of 111 posts

Re: lsix: ls for images

#61

Post by [deleted] »

kijin wrote: post #50
ObsoleteNerd wrote: post #34

Earlier quoted context omitted.

Are PDFs really expected to preview in an image viewer though? I don't really think of them as images, so I see the flag to preview them as more of an "extra feature", which is exactly what flags are for. If it didn't preview GIFs without a flag, or PNGs, then your point would absolutely stand.

Exactly. PDFs are documents, not images. Just because ImageMagick can convert PDFs into images doesn't make them images. Every image viewer on Earth excludes DOCs and PPTs by default, but nobody complains about that.

[deleted]

Re: lsix: ls for images

#63

Post by TeMPOraL »

kijin wrote: post #50
ObsoleteNerd wrote: post #34

Earlier quoted context omitted.

Are PDFs really expected to preview in an image viewer though? I don't really think of them as images, so I see the flag to preview them as more of an "extra feature", which is exactly what flags are for. If it didn't preview GIFs without a flag, or PNGs, then your point would absolutely stand.

Exactly. PDFs are documents, not images. Just because ImageMagick can convert PDFs into images doesn't make them images. Every image viewer on Earth excludes DOCs and PPTs by default, but nobody complains about that.

I recall at least one vector drawing program offering PDF as target, and this being expected in some print shops, so yes, in some cases, PDFs can be images.

PDF is a weird format with a bunch of disjoint use cases.

Re: lsix: ls for images

#64

Post by noja »

userbinator wrote: post #7

You can also specify filenames and, of course, use shell wild cards However, some may be slow to render (like PDF), so lsix doesn't show them unless you ask specifically. Regardless of the justification, I don't think creating such extra exception/edge-case behaviours are ever a good idea in a commandline tool like this. The equivalent in regular ls would be something like not showing more than X files "unless you as…

You are right. I think the behavior should be:

    toolName /somepath  # process all files the tool chooses to
    toolName /sompath/* # process every single file, even files it does not support (with a warning)
This is far closer to standard behavior.

Re: lsix: ls for images

#65

Post by petepete »

jopsen wrote: post #9

How many terminal emulators can handle sixel? (vt340) Does anyone have a list?

Not an exhaustive list I imagine, but here's the list from pysixel's readme.

RLogin (Japanese terminal emulator)

http://nanno.dip.jp/softlib/man/rlogin/

tanasinn (Works with firefox)

http://github.com/saitoha/tanasinn/

mlterm

Works on each of X, win32/cygwin, framebuffer version. http://mlterm.sourceforge.net/

XTerm (compiled with --enable-sixel option) You should launch xterm with "-ti 340" option. the SIXEL palette is limited to a maximum of 16 colors. http://invisible-island.net/xterm/

DECterm

Kermit

WRQ Reflection

ZSTEM

Re: lsix: ls for images

#66

Post by a1369209993 »

TeMPOraL wrote: post #63
kijin wrote: post #50

Earlier quoted context omitted.

Exactly. PDFs are documents, not images. Just because ImageMagick can convert PDFs into images doesn't make them images. Every image viewer on Earth excludes DOCs and PPTs by default, but nobody complains about that.

I recall at least one vector drawing program offering PDF as target, and this being expected in some print shops, so yes, in some cases, PDFs can be images. PDF is a weird format with a bunch of disjoint use cases.

GIMP offers ASCII art as a target, and that's expected by line printers/teletypewriters; does that mean TXTs can be images?

Re: lsix: ls for images

#67

Post by jchw »

a1369209993 wrote: post #66
TeMPOraL wrote: post #63

Earlier quoted context omitted.

I recall at least one vector drawing program offering PDF as target, and this being expected in some print shops, so yes, in some cases, PDFs can be images. PDF is a weird format with a bunch of disjoint use cases.

GIMP offers ASCII art as a target, and that's expected by line printers/teletypewriters; does that mean TXTs can be images?

Yeah, you just described how too. KDE used to thumbnail txt files with a portion of their actual text.

Re: lsix: ls for images

#68

Post by koshak »

Every time I see the word beginning from sumbol "l" I can’t tell whether it is "l" or "I"

The only font designers who care about clear distinction of symbols are those who create fonts for coders

Simple clarity test:

Il10O

All 5 chars should have clear distinction. Otherwise the font is shit.

Re: lsix: ls for images

#69

Post by chatmasta »

noja wrote: post #64
userbinator wrote: post #7

You can also specify filenames and, of course, use shell wild cards However, some may be slow to render (like PDF), so lsix doesn't show them unless you ask specifically. Regardless of the justification, I don't think creating such extra exception/edge-case behaviours are ever a good idea in a commandline tool like this. The equivalent in regular ls would be something like not showing more than X files "unless you as…

You are right. I think the behavior should be: toolName /somepath # process all files the tool chooses to toolName /sompath/* # process every single file, even files it does not support (with a warning) This is far closer to standard behavior.

In the second case, toolName would not be aware of the '*' unless it was single-quoted. Bash would expand it to match every file, and the toolName binary would see $argN as each filename.

Re: lsix: ls for images

#70

Post by y4mi »

koshak wrote: post #68

Every time I see the word beginning from sumbol "l" I can’t tell whether it is "l" or "I" The only font designers who care about clear distinction of symbols are those who create fonts for coders Simple clarity test: Il10O All 5 chars should have clear distinction. Otherwise the font is shit.

often, you can clearly distinguish them from each other... but still don't know which is which.

though i admit, that its become pretty normal for the I to be smaller than the l and the O to be rounder than the 0.

I'd prefer that to be even clearer. I.e. a point in the Zero or rounding the ends of the small L

Post reply on HN