موبائل ڈویلپمنٹ میں Descender — جوہر، اہمیت اور ترتیب پر اثر

ٹائپوگرافی میں Descender کیا ہے

Descender — گلیف کا وہ حصہ جو baseline لائن کے نیچے واقع ہوتا ہے۔ جہاں حرف کا مرکزی جسم baseline پر کھڑا ہوتا ہے، وہاں ڈیسنڈر اس کی حدود سے باہر نکل کر فونٹ کی مخصوص شکل بناتا ہے۔ سیریلک فونٹس میں ڈیسنڈر والے حروف r, u, f ہیں — ان کے نچلے عناصر لائن سے نیچے اترتے ہیں۔ اسی طرح لاطینی میں: g, j, p, q, y کے نچلے عناصر موجود ہیں۔

ڈیسنڈر کی گہرائی baseline سے گلیف کے نچلے کنارے (descender-line) تک کا فاصلہ بتاتی ہے۔ معیاری فونٹس میں یہ فاصلہ متوازن ہوتا ہے: بہت چھوٹا ڈیسنڈر r اور u حروف کو پہچاننا مشکل بنا دیتا ہے، جبکہ بہت لمبا ڈیسنڈر لائنوں کے درمیان ضرورت سے زیادہ خالی جگہ پیدا کرتا ہے اور متن کی کثافت کم کر دیتا ہے۔ مختلف فونٹ فیملیز ڈیسنڈر کی لمبائی میں نمایاں فرق ظاہر کرتی ہیں۔

Google Fonts Metrics Guide (2025) کے مطابق، ڈیسنڈر کو بہترین سمجھا جاتا ہے جب اس کی گہرائی مکمل em سائز (1000 FUnits) کا 20–25% ہو۔ 15% سے کم اقدار ڈیسنڈر والے حروف کو مشکل سے پہچاننے کے قابل بناتی ہیں، جبکہ 30% سے زیادہ اقدار لائنوں کے ٹکراؤ کو روکنے کے لیے line-height میں اضافے کا مطالبہ کرتی ہیں۔

Descender کی ڈیجیٹل میٹرکس: OpenType اور TrueType

ڈیجیٹل فونٹس میں ڈیسنڈر میٹرکس ٹیبلز میں منفی قدر کے طور پر محفوظ ہوتا ہے۔ OpenType فارمیٹ میں یہ hhea.descent (hhea ٹیبل) اور sTypoDescender (OS/2 ٹیبل) ہے۔ دونوں اقدار منفی ہیں کیونکہ یہ baseline سے نیچے ناپی جاتی ہیں۔ TrueType کے لیے OS/2 ٹیبل usWinDescent فیلڈ کے ساتھ استعمال ہوتا ہے — اس کی قدر مثبت ہے لیکن اسی میٹرک کو ظاہر کرتی ہے۔

# فونٹ سے fontTools کے ذریعے ڈیسنڈر پڑھنا
from fontTools.ttLib import TTFont

font = TTFont('Roboto-Regular.ttf')
hhea = font['hhea']
os2 = font['OS/2']

descent_hhea = hhea.descent        # -500 FUnits (Roboto)
typo_descender = os2.sTypoDescender # -500 FUnits
win_descent = os2.usWinDescent      # 500 (positive value)

# 16 pt فونٹ سائز کے لیے پکسلز میں تبدیل کریں
px_per_em = 16
descent_px = abs(descent_hhea) * px_per_em / 1000  # 8 px

پلیٹ فارمز کے درمیان اہم فرق: iOS رینڈرنگ کے لیے hhea.descent استعمال کرتا ہے، جبکہ Android — OS/2 سے sTypoDescender۔ اگر یہ اقدار مختلف ہوں (جو ناقص ترتیب شدہ فونٹس میں ہوتا ہے)، تو ایک ہی متن iOS اور Android پر مختلف لائن اسپیسنگ کے ساتھ دکھایا جائے گا۔ 100 FUnits کا فرق (16 pt کا سائز ہونے پر تقریباً 1.6 px) پہلے سے بصری طور پر نمایاں ہے۔

Microsoft OpenType Specification v1.9 (2025) کے مطابق، درست کراس پلیٹ فارم رینڈرنگ کے لیے hhea.descent اور sTypoDescender کی اقدار 50 FUnits تک کے فرق کے ساتھ برابر ہونی چاہئیں۔ موبائل ایپ کے لیے فونٹ منتخب کرتے وقت اسے fontTools یا اسی طرح کی یوٹیلیٹی سے چیک کرنا چاہیے۔

iOS میں Descender: UIFont اور Core Graphics

iOS میں ڈیسنڈر کی قدر UIFont.descender پراپرٹی سے دستیاب ہے۔ یہ پراپرٹی ایک منفی عدد لوٹاتی ہے جو baseline سے فونٹ کے نچلے کنارے (بشمول ڈیسنڈر) تک کا فاصلہ ظاہر کرتی ہے۔ مثال کے طور پر، SF Pro کے لیے 17 pt سائز پر ڈیسنڈر کی قدر ≈ -4.2 pt ہے۔ عدد کی مطلق قدر جتنی بڑی ہوگی، فونٹ کے نچلے عناصر اتنے ہی لمبے ہوں گے۔

// iOS میں UIFont کے ذریعے ڈیسنڈر حاصل کرنا
let font = UIFont.systemFont(ofSize: 17)
let descender = font.descender     // ~ SF Pro 17pt کے لیے -4.2 pt
let ascender = font.ascender        // ~ 16.2 pt
let lineHeight = font.lineHeight    // ~ 20.4 pt

// ڈیسنڈر آفسیٹ کے ساتھ کسٹم رینڈرنگ
let attrString = NSAttributedString(
    string: "Sample text with letter p and y",
    attributes: [.font: font]
)

// Core Text: ڈیسنڈر کے ساتھ باؤنڈنگ باکس حاصل کرنا
let ctFont = CTFontCreateWithName(
    "SF Pro Text" as CFString, 17, nil
)
let descent = CTFontGetDescent(ctFont)  // ~4.2 pt

TextKit (NSTextStorage, NSLayoutManager) استعمال کرتے وقت ڈیسنڈر خود بخود lineFragmentPadding اور lineFragmentRect میں شامل ہوتا ہے۔ تاہم Core Graphics (draw(in:)) کے ذریعے کسٹم ڈرائنگ میں کنٹینر کے نچلے مارجن میں ڈیسنڈر کی مطلق قدر شامل کر کے کوآرڈینیٹس خود درست کرنا ضروری ہے۔ ایسا نہ کرنے پر ڈیسنڈر والے حروف ڈرائنگ کی حد سے باہر نکل کر کٹ جائیں گے۔

Android میں Descender: Paint اور Compose

Android میں ڈیسنڈر کی میٹرکس Paint.FontMetrics.descent سے دستیاب ہیں۔ iOS کے برعکس، descent کی قدر مثبت ہے — یہ baseline سے متن کے نچلے کنارے تک کا فاصلہ ہے۔ FontMetrics.bottom پراپرٹی میں صرف ڈیسنڈر ہی نہیں بلکہ وہ اضافی جگہ بھی شامل ہوتی ہے جو فونٹ ڈیزائنر نے تجویز کی ہے (leading)۔ صرف ڈیسنڈر کے درست حساب کے لیے bottom کی بجائے descent استعمال کریں۔

// Android میں Paint کے ذریعے ڈیسنڈر حاصل کرنا
val paint = Paint().apply {
    textSize = 17 * density
}

val metrics = paint.fontMetrics
val descent = metrics.descent     // ~17sp کے لیے 4.5 px
val bottom = metrics.bottom       // ~leading کے ساتھ 5.0 px

// ڈیسنڈر آفسیٹ کے ساتھ کسٹم رینڈرنگ
val baseline = y
canvas.drawText("نمونہ: gpq", x, baseline, paint)

// ڈیسنڈر کے ساتھ نچلی حد
val bottomBound = baseline + descent  // درست نچلی حد

Jetpack Compose میں ڈیسنڈر TextLayoutResult کے ذریعے حاصل کیا جا سکتا ہے۔ getLineBottom میتھڈ لائن کے نچلے کنارے کا Y-کوآرڈینیٹ لوٹاتی ہے جو پہلے سے ڈیسنڈر شامل کرتی ہے۔ مختلف سائزوں والی لائنوں کی کسٹم ترتیب میں (مثال کے طور پر رعایت والی قیمت اور مکمل قیمت) ڈیسنڈر کے ساتھ baseline پر الائنمنٹ نچلے کنارے پر الائنمنٹ سے زیادہ درست نتیجہ دیتی ہے۔

// Compose: متن کی نچلی حد کی جانچ
val text = "Text with descenders: gpq"
var layoutResult by remember { mutableStateOf<TextLayoutResult?>(null) }

Text(
    text = text,
    onTextLayout = { layoutResult = it },
    modifier = Modifier.drawBehind {
        layoutResult?.let { result ->
            val lastLine = result.lineCount - 1
            val bottom = result.getLineBottom(lastLine)
            val top = result.getLineTop(lastLine)
            // چیک کریں کہ ڈیسنڈر کنٹینر کی حدود سے باہر نہ جائے
        }
    }
)

Google Material Design — Typography Implementation (2025) کے مطابق، فکسڈ اونچائی والے کنٹینرز میں ڈیسنڈر کے کٹنے سے بچنے کے لیے عمودی padding شامل کرنا ضروری ہے جو کم از کم فونٹ کے descent کے برابر ہو، چاہے موجودہ متن میں ڈیسنڈر والے حروف نہ ہوں۔ اس سے یہ یقینی ہوتا ہے کہ متن کی ڈائنامک تبدیلی پر انٹرفیس نہ ٹوٹے۔

Descender اور موبائل انٹرفیسز میں لائنوں کا ٹکراؤ

لائنوں کا ٹکراؤ (line collision) — وہ صورت حال جب اوپری لائن کے کسی حرف کا ڈیسنڈر جسمانی طور پر نچلی لائن کے کسی حرف کے ascender سے ٹکرا جاتا ہے۔ موبائل انٹرفیسز میں یہ خاص طور پر کثیرالسطری عنوانات، پروڈکٹ کارڈز اور کم لائن اسپیسنگ والے ٹیکسٹ بلاکس میں نمایاں ہوتا ہے۔ لمبے ڈیسنڈر والے فونٹس اور کم line-height کے استعمال سے مسئلہ مزید بڑھ جاتا ہے۔

ٹکراؤ کو روکنے والا کم سے کم line-height فارمولے سے نکالا جا سکتا ہے: line-height = ascender + descender + 2 px کا مارجن۔ SF Pro کے لیے 17 pt سائز پر یہ line-height ≈ 16.2 + 4.2 + 2 = 22.4 pt (تقریباً 1.32 کا تناسب) دیتا ہے۔ Roboto کے لیے 16 sp سائز پر تقریباً 1.35۔ اگر line-height اس قدر سے کم ہو تو r, u, g گروپ کے حروف والے متن میں ٹکراؤ یقینی ہے۔

// iOS: ٹکراؤ سے بچنے کے لیے کم سے کم line-height کا حساب لگائیں
let font = UIFont.systemFont(ofSize: 17)
let minLineHeight = abs(font.ascender) + abs(font.descender) + 2.0

let paragraphStyle = NSMutableParagraphStyle()
paragraphStyle.minimumLineHeight = minLineHeight
paragraphStyle.maximumLineHeight = minLineHeight

let attributedText = NSAttributedString(
    string: "Text with p on first line\nand y on second line",
    attributes: [
        .font: font,
        .paragraphStyle: paragraphStyle
    ]
)

آرائشی اور ہاتھ سے لکھے فونٹس کے ساتھ کام کرتے وقت خاص احتیاط برتنی چاہیے — ان کا ڈیسنڈر em سائز کا 35–40% تک پہنچ سکتا ہے۔ ایسے فونٹس عام متن کے لیے شاذ و نادر ہی استعمال ہوتے ہیں، لیکن عنوانات میں استعمال ہو سکتے ہیں۔ عنوان میں لمبے ڈیسنڈر والا ایک ہی حرف پڑوسی انٹرفیس عنصر کے ساتھ ٹکراؤ پیدا کر سکتا ہے۔

Descender کے ساتھ کام کرتے وقت عام غلطیاں

سب سے عام غلطی بٹنوں اور ٹیکسٹ فیلڈز میں ڈیسنڈر کا کٹ جانا ہے۔ جب ہم بٹن یا ٹیکسٹ فیلڈ کی اونچائی line-height کے برابر مقرر کرتے ہیں، ڈیسنڈر کا لحاظ کیے بغیر، r, u اور f حروف نچلے کنارے سے کٹ جاتے ہیں۔ یہ خاص طور پر گول کناروں والے سسٹم بٹنوں پر نمایاں ہوتا ہے، جہاں ڈیسنڈر گولائی کی حد سے باہر نکل سکتا ہے۔

• فکسڈ اونچائی والے بٹن — اگر بٹن کی اونچائی ceil(line-height) کے برابر ہو تو ڈیسنڈر والے حروف کٹ جاتے ہیں۔ حل: بٹن کی اونچائی کو ڈیسنڈر کی مطلق قدر (17 pt سسٹم فونٹ کے لیے 4–5 pt) تک بڑھائیں، اوپر اور نیچے کے مارجن دونوں کے لیے۔
• ڈیسنڈر کے بغیر TextField — معیاری UITextField اور EditText میں ڈیسنڈر کو مدنظر رکھنے والا padding ہوتا ہے، لیکن کسٹم امپلیمینٹیشنز اکثر اسے بھول جاتی ہیں۔ چیک کریں کہ کرسر اور ٹیکسٹ بلاک r اور u کو نہ کاٹیں۔
• ایک ہی لائن میں سائزوں کا ملاپ — اگر NSAttributedString یا SpannableString میں مختلف سائز والے حصے ہوں تو بڑے فونٹ کا ڈیسنڈر چھوٹے فونٹ کے ascender پر چڑھ سکتا ہے۔ معاوضے کے لیے baselineOffset استعمال کریں اور نتیجہ چیک کریں۔
• SVG متن رینڈرنگ — SVG یا Canvas (خاص طور پر ویب ویو میں) میں متن ڈرائنگ کرتے وقت ڈیسنڈر خود بخود مدنظر نہیں آ سکتا۔ ہمیشہ واضح viewBox مقرر کریں جس میں سائز کا 10–15% مارجن ہو۔

Nielsen Norman Group — Mobile Typography Research (2025) کے مطابق، 41% موبائل ایپس میں کم از کم ایک ایسی اسکرین ہے جہاں ڈیسنڈر والا متن کمپوننٹ کی حدود سے باہر نکل جاتا ہے۔ اس سے پڑھنے کی اہلیت 15% کم ہو جاتی ہے اور صارف کے کام مکمل کرنے کا وقت بڑھ جاتا ہے۔ r, u, f (اور لاطینی کے لیے g, j, p) حروف والے متن کے ساتھ باقاعدہ ٹیسٹنگ ڈیولپمنٹ کے ابتدائی مراحل میں ایسی مشکلات پکڑنے میں مدد دیتی ہے۔