1 पॉइंट द्वारा GN⁺ 3 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Justif एक web demo है जो browser के default rendering और publication-level text justification की सीधी तुलना करता है
  • hyphenation और character protrusion, width expansion, letter spacing adjustment, और last line spacing alignment को अलग-अलग configure किया जा सकता है
  • minimum last line width और hanging punctuation range को adjust किया जा सकता है, और text-wrap: pretty लागू करने के परिणाम से भी तुलना संभव है
  • English literature और technical documents के साथ-साथ Hebrew/Arabic RTL text और Japanese को serif, sans, monospace typefaces में test किया जा सकता है
  • line count, hyphenated line breaks, overflowing lines, short last lines, space deviation और rivers आदि को browser rendering के साथ side-by-side measure करता है

Justification और detailed settings

  • Justif को web पर Knuth-Plass justification और कई microtypography features test करने के लिए बनाया गया है
    • hyphenation
    • character protrusion
    • width expansion
    • letter spacing adjustment
    • last line spacing alignment
  • Hanging punctuation का उपयोग करने के लिए character protrusion enable होना चाहिए, और इसे line ends व first line starts या पूरे range पर apply किया जा सकता है
  • minimum last line width को 0.33, और body width को 13em पर adjust किया जा सकता है

Text, typeface comparison और measurement

  • Alice in Wonderland, Frog Prince, Frankenstein, Ulysses, technical posts, RFC 2324, और type specimen में से comparison के लिए text चुना जा सकता है
  • Hebrew/Arabic RTL text और Japanese text भी उपलब्ध हैं
  • supported typefaces में Junicode, EB Garamond, Alegreya, IM Fell English, Vollkorn, Amstelvar, Latin Modern, Georgia, Roboto Flex, Courier Prime, IBM Plex Mono और system fonts शामिल हैं
  • result पर click या long-press करने से browser default rendering दिखाई देता है, जिससे Justif rendering से तुलना की जा सकती है
  • comparison tool text-wrap: pretty, blur effect, margin ruler, और uneven spaces display को support करता है
  • measurements में line count, hyphenated line breaks, overflowing lines, short last lines, rivers के साथ average space, natural space के मुकाबले average deviation, standard deviation, और widest space शामिल हैं

1 टिप्पणियां

 
GN⁺ 3 시간 전
Lobste.rs की राय
  • इस प्रोजेक्ट को Fable में vibe coding करके बनाया गया था https://news.ycombinator.com/item?id=48946738#49002419

    • लेख का विषय vibe coding नहीं है, फिर भी क्या यह टैग सच में ज़रूरी है, इस पर संदेह है
      मुझे LLM उपयोग के अनुभव पढ़ने में दिलचस्पी नहीं है इसलिए मैं उन्हें फ़िल्टर करना चाहता हूँ, लेकिन लगता है कि अगर सिर्फ़ इतना भी शक हो कि coding assistant इस्तेमाल हुआ था, तो लेख से असंबंधित होने पर भी यह टैग लगा दिया जाता है
      इस बार उपयोग होना स्पष्ट है, लेकिन मैंने ऐसे मामले भी देखे हैं जहाँ सिर्फ़ इसलिए प्रोजेक्ट पोस्ट पर यह टैग लगा दिया गया क्योंकि वे coding assistant इस्तेमाल करने वाले contributors को स्वीकार करते हैं
    • यह व्यक्ति बिना झिझक मानता है कि इस प्रोजेक्ट को बनाते समय उसने LLM का इस्तेमाल किया था
      लेकिन vibe coding शब्द और यहाँ इस्तेमाल किया जाने वाला टैग अब अपनी उपयोगिता खो चुके हैं, और LLM उपयोग पर लिखे गए लेखों तथा ऐसे परिणामों के बीच फ़र्क करने के लिए अधिक सटीक और उपयोगी अभिव्यक्ति चाहिए जिनके निर्माण के दौरान बस संयोग से LLM का उपयोग हुआ हो
    • लॉब्स्टर 1: “उन्होंने कैंसर का इलाज करने वाली दवा बना ली!”
      लॉब्स्टर 2: “ठीक है… लेकिन उन्होंने AlphaFold, CRISPR, और… ढम-ढम… Fable इस्तेमाल किया”
      लॉब्स्टर 1: “हे भगवान, यह अस्वीकार्य है! मानवता के लिए सब कुछ फेंक दो और फिर से ब्लैकबोर्ड पर रंगीन पेंसिल से protein बनाते हुए 40 साल बिताएँ!”
  • नतीजा बेहद शानदार है, और microtype पैकेज के बिना TeX से भी बेहतर है
    ऐसे typesetting features ब्राउज़र को खुद संभालने चाहिए
    कुछ ब्राउज़रों ने text-wrap: pretty लागू किया है, लेकिन लगता है कि यह सिर्फ़ कुछ लाइनों तक सीमित है

    • आजकल Safari में pretty ठीक से लागू है, लेकिन justify के साथ इस्तेमाल करने पर bug है
      https://matklad.github.io/2026/02/14/justifying-text-wrap-pretty.html
    • text-wrap: pretty spec देखने पर पता चलता है कि इसका व्यवहार परिभाषित नहीं है, यह सिर्फ़ एक hint है
      बस इतना कहा गया है कि user agent को speed से ज़्यादा बेहतर layout को प्राथमिकता देनी चाहिए और line breaks तय करते समय कई लाइनों पर विचार करना चाहिए; इसके अलावा यह auto जैसा ही है
      यह बहुत छोटी आख़िरी पंक्ति, टेक्स्ट लाइनों के बीच नदी जैसी दिखने वाली खाली जगह, और लगातार आने वाले hyphens से बचा सकता है, लेकिन सही सुधार कैसे होगा यह हर ब्राउज़र में अलग है
      मुझे याद है कि यह spec में इसलिए डाला गया था ताकि बहुत ज़्यादा पाबंदियों से बचा जा सके, क्योंकि कई ब्राउज़र इसे अलग-अलग तरीके से implement करना चाहते थे
      मामला कुछ वैसा ही है जैसा Web SQL को इसलिए छोड़ दिया गया क्योंकि यह साफ़ हो गया था कि implementations आख़िरकार SQLite ही इस्तेमाल करेंगी
      उम्मीद है कि किसी दिन ये features text-wrap: auto में डिफ़ॉल्ट रूप से लागू हो जाएँगे और text-wrap: pretty का कोई असर नहीं बचेगा, और https://bugzilla.mozilla.org/show_bug.cgi?id=630181 भी लागू होगा
      ऐसे hints नए नहीं हैं; will-change भी पिछली पीढ़ी के ब्राउज़रों के लिए optimization hint था
      जब इसे spec किया जा रहा था तब तक Firefox में इसकी ज़्यादातर ज़रूरत नहीं रह गई थी, और कुछ अगली पीढ़ी के engines में तो यह बिल्कुल मददगार भी नहीं था, फिर भी इसका भारी दुरुपयोग हुआ; ऐसे में शायद साफ़ तौर पर hack रहे transformZ(0) को ही रहने देना बेहतर होता
    • आदर्श दुनिया में इस लाइब्रेरी के अस्तित्व की ज़रूरत ही नहीं होती
      डेमो में text-wrap: pretty को on/off करके ब्राउज़र-वार व्यवहार आज़माया जा सकता है, और Blink·WebKit·Gecko का व्यवहार हैरान कर देने लायक अलग है, इसलिए इसे कई ब्राउज़रों में देखकर समझना चाहिए
  • मुझे लंबे समय से लगता रहा है कि hanging punctuation आम तौर पर ज़रूरत से ज़्यादा लागू की जाती है
    अगर यह नज़र आ जाए तो यह पहले ही ज़्यादा है, और खासकर लगभग हमेशा उभरकर दिखता है, इसलिए इसे अभी के आधे से भी कम बाहर निकलना चाहिए
    उल्टा, पैराग्राफ़ की शुरुआत में का छोटे indentation की तरह काम करना मुझे पसंद है
    hanging को बंद करके सिर्फ़ हल्का protrusion चालू रखने का नतीजा सहने लायक है, लेकिन ज़्यादातर मामलों में मैं दोनों को बंद रखना पसंद करता हूँ
    यह सब फ़ॉन्ट पर बहुत निर्भर करता है
    मेरे इस्तेमाल वाले serif फ़ॉन्ट Equity में अगर पंक्ति के अंत के “f,” पर इसे लागू करें, तो kerning की वजह से comma पहले से ही f के नीचे चला जाता है, इसलिए f का ऊपरी हिस्सा भी लाइन के बाहर निकल जाता है और अटपटा लगता है
    अगर serif फ़ॉन्ट अक्षरों की पूँछ या उभार को character width के बाहर रखकर स्वाभाविक रूप से बाहर निकालते हैं, तो वे ज़्यादातर punctuation से ज़्यादा उपयुक्त लक्ष्य लगते हैं
    letter-spacing में letter-spacing ligatures के साथ ठीक से काम नहीं करता, इसलिए यह जोखिम भरा है
    अगर ligatures पहले लागू हों, तो चीज़ “T h i s i s fi n e!” जैसी बनती है, और अगर non-zero letter-spacing ligatures को बंद कर दे, तो f, i की बिंदी से टकराता है
    ज़्यादातर बार दूसरा मामला दिखता है, लेकिन यह script, फ़ॉन्ट, और स्पष्ट रूप से enabled OpenType features पर निर्भर करता है, और अनजाने में भी आसानी से हो सकता है

    • निजी तौर पर मुझे hanging punctuation का रूप पसंद है, लेकिन निश्चित ही इसे setting से बदला जा सकता है
      मैं सहमत हूँ कि ligatures की वजह से letter-spacing मुश्किल हो जाता है, लेकिन डिफ़ॉल्ट सीमा ±3% हो तो मुझे यह ठीक दिखता है
      “Type Specimen” उदाहरण के पहले पैराग्राफ़ के अंत में fl, fi, ffi ligatures का लगातार आने वाला हिस्सा देखा जा सकता है, और 3% सीमा भी configure की जा सकती है
    • कुछ Swedish साइटों पर opening right double quote का पिछली लाइन के अंत में अकेला रह जाना मुझे चिढ़ाता था, और शायद इसे punctuation hanging से समझाया जा सकता है
      Swedish में उद्धरण की शुरुआत और अंत दोनों के लिए सिर्फ़ right double quote का इस्तेमाल होता है
      मैं लंबे समय से सोचता रहा हूँ कि क्या टेक्स्ट की भाषा या locale ब्राउज़र को बताने का कोई तरीका है ताकि वह quotes, decimal points वगैरह को अपने-आप संभाल सके
  • मैं यह बताना चाहता हूँ कि उदाहरणों में सुधार के असर को उभारने के लिए कृत्रिम रूप से संकीर्ण line width इस्तेमाल की गई थी
    आम तौर पर सलाह दी जाती है कि एक पंक्ति की चौड़ाई lowercase alphabet के लगभग दो सेट, यानी करीब 60 characters होनी चाहिए

    • लगता है पुराने अख़बारों के कॉलम भी उदाहरण जितने ही चौड़े होते थे, लेकिन इसका मतलब यह नहीं कि आज भी वही मानक अपनाया जाए
    • कॉलम की चौड़ाई बढ़ाकर वास्तविक body text width पर तुलना की जा सकती है
      फ़र्क काफ़ी कम नाटकीय रहता है, लेकिन फिर भी साफ़ दिखता है, और 36em line width पर भी आँकड़े डिफ़ॉल्ट से बहुत बेहतर आते हैं
  • सोचता हूँ कि कहीं दूसरे साइट पर लेखक द्वारा LLM इस्तेमाल करने की बात कहने की वजह से ही यह vibe coding टैग तो नहीं लगा दिया गया
    लिंक की सामग्री का LLM या vibe coding से कोई लेना-देना नहीं है, इसलिए अब यह टैग witch hunt जैसा महसूस होता है

    • थोड़ा उदार होकर देखें तो यह टैग दो भूमिकाएँ निभाता है, और लेख vibe coding के बारे में है यह बताने के अलावा इसे अक्सर content warning की तरह भी लगाया जाता है
      यह अपने ज़्यादा स्पष्ट उपयोग से टकराकर भ्रम पैदा करता है और ज़रूरत से ज़्यादा आक्रामक भी लग सकता है
      एक ही टैग का दो उद्देश्य होना आदर्श नहीं है, लेकिन कुल मिलाकर मैं content warning और नापसंद चीज़ों को मनचाहे ढंग से फ़िल्टर करने की सुविधा के पक्ष में हूँ
      टैग भले भ्रमित करने वाला हो, कम-से-कम यह लेखक को नुकसान नहीं पहुँचाता