Ecosyste.ms: Awesome
An open API service indexing awesome lists of open source software.
https://github.com/rudxain/custom-emoji-inliner
takes a table of icon URLs, and it'll replace ":emoji_id:" by its corresponding <img> within any input file
https://github.com/rudxain/custom-emoji-inliner
emojis github-style html icon icons img isotype markdown svg wip
Last synced: about 5 hours ago
JSON representation
takes a table of icon URLs, and it'll replace ":emoji_id:" by its corresponding <img> within any input file
- Host: GitHub
- URL: https://github.com/rudxain/custom-emoji-inliner
- Owner: Rudxain
- License: mpl-2.0
- Created: 2023-10-16T23:48:10.000Z (about 1 year ago)
- Default Branch: main
- Last Pushed: 2024-04-02T07:10:29.000Z (8 months ago)
- Last Synced: 2024-04-03T07:43:28.596Z (8 months ago)
- Topics: emojis, github-style, html, icon, icons, img, isotype, markdown, svg, wip
- Language: Python
- Homepage:
- Size: 55.7 KB
- Stars: 1
- Watchers: 1
- Forks: 0
- Open Issues: 4
-
Metadata Files:
- Readme: README.md
- License: LICENSE
Awesome Lists containing this project
README
# CEI
This will be a ~~Python script~~ Rust CLI (main program) and JS web-app (playground) that parses a "definitions-file" from working-directory (or parent dirs), and it replaces GH/Discord-style "emoji references" (that's how I call them) with the corresponding HTML `` element. The default global sizes of all emojis is `16em` rather than `2em`, because of how GH's markdown-renderer works. An [example end-product](https://github.com/Rudxain/Rudxain/blob/main/README.md#langs) can be found at my profile.
For convenience, the script will provide [its own (built-in) emoji name-space](cei-def.csv), which contains commonly used emojis such as lang-logos and mascots. 3rd-party defs have precedence over built-in, so you can easily override any def with your preferred URI.
CEI could be considered a _"Markdown framework"_, but it's too simple to be something so big.
It'll be designed for use on GH, but it can be used to generate HTML files with custom emojis (although this might **completely break** your HTML if you aren't careful), as it'll be fully format-agnostic (content-format and filename-extension are irrelevant). The input text-file to be processed can be in any encoding, however the **emoji-defs must be UTF-8**.
If you need advanced-management and/or auto-updates/hot-reloading for specific file-lists and globs, you'll need `make` and a make-file. I won't implement advanced features, as this script is meant to be "basic".
## Name
- "custom": Because it supports anything that can be considered an emoji, regardless if it's "officially-Unicode" or made-up.
- "emoji": Actually 🤓, it supports any *graphical icon*, not just emojis. But because of how they look when rendered, they are indeed "emojis", [according to Wikipedia](https://en.wikipedia.org/wiki/Emoji).
- "inliner": This one packs 2 meanings in 1!
- it does "variable-inlining" similarly to compilers
- it literally replaces the "variable" by its value, within a line of text, rather than inserting the `` element on its own line (as usual in HTML).## Why?
- It helps manage/maintain custom emojis for a single file, or an entire directory. So (similarly to Discord servers) you can have **entire repos** with custom-emojis, and users can copy your defs/macros file to easily post comments with your emojis! (yes! this includes Issues, PRs, and Discussions!)
- Reduces bandwidth use by ensuring the same exact URL is shared across refs/macros. This has the side-effect of reducing generated cache.
- All inlined `img`s will have the same structure/pattern, which increases compression-ratio.
- Your source text-files can be readable/pretty by using refs, while the macro-expanded files are the only ones with inline-HTML.
- You can change the size of all emojis from a single config field.
- Optionally use a non-default size for specific emojis. **Only do this if you can't resize the origin image** (this is the case if the URL points to a server you don't own)
- Optional `alt` & `title` attributes for accessibility## Disclaimer
It should be obvious by now that the **CLI API and the defs-file are very unstable**, so expect many breaking-changes while I decide how it's going to be stabilized. You can help me take better design-decisions by opening an issue