మీరు ఎప్పుడైనా PDF నుండి bold లేదా italic టెక్స్ట్ను తీయడానికి ప్రయత్నిస్తే, బహుశా మీరు regexతోనే మొదలుపెట్టి ఉంటారు. ఇది చాలా సహజమైన పద్ధతిలా అనిపిస్తుంది. ఫాంట్ పేరులో “Bold” అనే పదం కోసం వెతకడం, ఆ టెక్స్ట్ను గుర్తించడం మరియు ముందుకు సాగడం. ఆ వ్యూహం మీకు తప్పుడు నమ్మకాన్ని కలిగించేంత వరకు మాత్రమే పనిచేస్తుంది. ఆ తర్వాత ఎవరైనా అదే డాక్యుమెంట్ను Acrobat యొక్క వేరే వెర్షన్ నుండి, లేదా LibreOffice నుండి, లేదా print-to-PDF driver నుండి ఎగుమతి (export) చేసినప్పుడు, మీరు కోడ్ చేసిన ప్రతి ఊహ విఫలమవుతుంది.
ఫాంట్ పేర్లు ఎందుకు తప్పుగా చెబుతాయి
PDF.js మీకు ABCDEF+TimesNewRomanPS-BoldMT వంటి స్ట్రింగ్స్ను అందిస్తుంది. మొదటి ఆరు అక్షరాలు ఎగుమతి సమయంలో జోడించబడిన రాండమ్ ప్రిఫిక్స్ (random prefix), మరియు ఫైల్ ప్రతిసారి రీజనరేట్ అయినప్పుడు ఇవి మారుతూ ఉంటాయి. మీ పార్సర్ను ఆ ప్రిఫిక్స్ మీద ఆధారపడేలా చేయడం అంటే అనవసరమైన డేటా (noise) మీద పందెం వేయడమే. ఇతర ఎగుమతి చేసే సాధనాలు (exporters) ఇంకా తక్కువ సహాయకారిగా ఉంటాయి. కొన్ని Font12 లేదా F1 వంటి సాధారణ ఐడెంటిఫైయర్లను మాత్రమే ఇస్తాయి. ఈ లేబుల్స్కు ఎటువంటి అర్థం ఉండదు; ఇవి ఫైల్ వ్రాయబడినప్పుడు అక్కడ ఉన్న అంతర్గత రిసోర్స్ ట్యాగ్లు మాత్రమే.
Portable Document Format అనేది టెక్స్ట్ ఎక్స్ట్రాక్షన్ను సులభతరం చేసేలా రూపొందించబడలేదు, కాబట్టి ఫాంట్ పేర్లు కేవలం ఎంబెడెడ్ (embedded) లేదా సబ్సెట్ చేయబడిన రిసోర్స్లకు సంబంధించిన రిఫరెన్స్లు మాత్రమే. స్టైల్ డిటెక్షన్ కోసం స్థిరమైన APIగా పనిచేయాలని వీటిని ఎప్పుడూ ఉద్దేశించలేదు. మీరు Bold లేదా Italic అనే సబ్స్ట్రింగ్ కోసం regex రాసినప్పుడు, మీరు సృష్టించిన అప్లికేషన్ తనకు నచ్చినట్లుగా ఫార్మాట్ చేసిన ఒక లేబుల్ను మాత్రమే సేకరిస్తున్నారు. మీరు అసలైన టైపోగ్రాఫిక్ లక్షణాలను (typographic properties) చదవట్లేదు. మీరు కేవలం ఒక ఫైల్-నేమింగ్ కన్వెన్షన్ను చదువుతున్నారు, మరియు కన్వెన్షన్లు ఒప్పందాలు (contracts) కావు.
లేబుల్ను కాకుండా, డిస్క్రిప్టర్ను చదవండి
అసలైన సమాచారం వేరే చోట ఉంటుంది. PDF.jsలో, ప్రతి పేజీ ఆబ్జెక్ట్ commonObjsను ఎక్స్పోజ్ చేస్తుంది, ఇది పేజీని రెండర్ చేయడానికి అవసరమైన నిజమైన ఫాంట్ డిస్క్రిప్టర్లను కలిగి ఉన్న ఒక మ్యాప్. లైబ్రరీ ఒక పేజీని పార్స్ చేసినప్పుడు, ఇది ఈ మ్యాప్ను అసలైన ఫాంట్ ఆబ్జెక్ట్లతో నింపుతుంది. ఆ ఆబ్జెక్ట్లు bold మరియు italic కోసం బూలియన్ (boolean) ప్రాపర్టీలను ఎక్స్పోజ్ చేస్తాయి. ఆ బూలియన్ విలువలు పేరులోని స్ట్రింగ్ నుండి తీసుకోబడవు. అవి PDF లోపల ఎంబెడ్ చేయబడిన ఫాంట్ డిస్క్రిప్టర్ నుండి వస్తాయి, ఇవి గ్లిఫ్ మెట్రిక్స్ (glyph metrics), OS/2 టేబుల్ ఫ్లాగ్స్ మరియు టైప్సెట్టర్ డాక్యుమెంట్లో వ్రాసిన సింబాలిక్ డిస్క్రిప్టర్ల నుండి సేకరించబడతాయి.
అంటే మీరు ఊహించడం ఆపేయవచ్చు. ఒక పేజీలోని టెక్స్ట్ ఐటమ్స్ను ప్రాసెస్ చేసే ముందు, page.commonObjs ద్వారా ఇటరేట్ చేయడం ద్వారా ఒక fontStyleMapను సృష్టించండి. ప్రతి ఫాంట్ ID కోసం, ఫాంట్ ఆబ్జెక్ట్ అందించే అసలైన .bold మరియు .italic ప్రాపర్టీలను రికార్డ్ చేసే ఒక ఆబ్జెక్ట్ను నిల్వ చేయండి. తర్వాత, మీరు ప్రతి టెక్స్ట్ ఐటమ్ను ప్రాసెస్ చేసేటప్పుడు, మీ మ్యాప్లో దాని ఫాంట్ రిఫరెన్స్ను వెతికి, ముందుగా లెక్కించిన (precomputed) ఫ్లాగ్లను చదవండి. దీనివల్ల మీకు ఎగుమతుల (exports) మధ్య మారని ఒక ఖచ్చితమైన (deterministic) సమాధానం లభిస్తుంది.
మీరు ఒక ఫాల్బ్యాక్ (fallback) పద్ధతిని ఉంచుకోవచ్చు. ఒకవేళ డిస్క్రిప్టర్ లేకపోయినా లేదా అసంపూర్తిగా ఉన్నా, ఫాంట్ పేరును క్లీన్ చేసి, ప్రిఫిక్స్ను తొలగించి, రాండమ్ ట్యాగ్లను తీసివేసి, మిగిలిన దానిపై ఒక జాగ్రత్తగా ఉన్న regexను రన్ చేయండి. కానీ ఇది మీ చివరి ప్రయత్నం మాత్రమే కావాలి, మీ ప్రాథమిక లాజిక్ కాదు. విశ్వసనీయతలో తేడా చాలా స్పష్టంగా ఉంటుంది. పేరు ఆధారిత పార్సింగ్ వివిధ ఎగుమతి సాధనాల వద్ద విఫలమవుతుంది, కానీ డిస్క్రిప్టర్ ఆధారిత పార్సింగ్ స్థిరంగా ఉంటుంది, ఎందుకంటే అది ఫైల్లో అసలు ఏముందో అడుగుతుంది.
ఫాంట్ కూడా తప్పుగా చెప్పినప్పుడు: సింథటిక్ స్టైల్స్ (Synthetic Styles)
డిస్క్రిప్టర్ కూడా కొన్నిసార్లు తప్పుగా ఉండవచ్చు. కొన్ని PDF క్రియేటర్లు ప్రత్యేకమైన italic టైప్ఫేస్ను ఎంబెడ్ చేయడానికి కష్టపడరు. దానికి బదులుగా, వారు నిటారుగా ఉన్న రోమన్ ఫాంట్ను తీసుకుని, ఒక transform మ్యాట్రిక్స్తో వాలుగా (slant) మారుస్తారు. టైపోగ్రాఫిక్ స్వచ్ఛత కంటే ఫైల్ సైజుకు ప్రాధాన్యత ఇచ్చే డిజైన్ టూల్స్ లేదా పాత వర్డ్ ప్రాసెసర్ల ద్వారా రూపొందించబడిన ఫైల్లలో ఇది సాధారణం.
PDF.jsలోని ప్రతి టెక్స్ట్ ఐటమ్ ఒక transform అర్రేను కలిగి ఉంటుంది, ఇది గ్లిఫ్ కోఆర్డినేట్ సిస్టమ్ను పేజీ కోఆర్డినేట్ సిస్టమ్లోకి మ్యాప్ చేసే ఆరు ఎలిమెంట్స్ కలిగిన అఫైన్ మ్యాట్రిక్స్ (affine matrix). ఆ అర్రేలోని మూడవ ఎలిమెంట్ హారిజాంటల్ షియర్ (horizontal shear)ను నియంత్రిస్తుంది. ఆ విలువ సున్నా కానప్పుడు, టెక్స్ట్ రెండరర్ ద్వారా మెకానికల్గా వాలుగా మార్చబడుతుంది. మీరు కేవలం ఫాంట్ డిస్క్రిప్టర్ను మాత్రమే నమ్మితే, ఈ టెక్స్ట్ను నిటారుగా ఉన్న రోమన్ అని వర్గీకరిస్తారు. మీరు మ్యాట్రిక్స్ను పరిశీలిస్తే, ఆ సింథటిక్ ఇటాలిక్ను గుర్తించి సరిగ్గా మార్క్ చేయగలరు. ఓవర్ప్రింటింగ్ ద్వారా సృష్టించబడిన సింథటిక్ బోల్డ్కు కూడా ఇదే లాజిక్ వర్తిస్తుంది, అయితే కేవలం జ్యామితి (geometry) ద్వారా దానిని గుర్తించడం కష్టం. వాలుగా ఉన్న టెక్స్ట్ కోసం, షియర్ విలువ (shear value) మీకు ఖచ్చితమైన ఆధారంగా పనిచేస్తుంది.
అండర్లైన్లు గీయబడతాయి, ప్రకటించబడవు
Bold మరియు italic అనేవి ఫాంట్ ప్రాపర్టీలు. అండర్లైన్ అలా కాదు. PDFలో, అండర్లైన్ అనేది ఒక వెక్టర్ పాత్ (vector path). టెక్స్ట్ బేస్లైన్ దగ్గర ఉన్న సన్నని హారిజాంటల్ సెగ్మెంట్ కోసం రెండరర్ ఒక డ్రాయింగ్ కమాండ్ను జారీ చేస్తుంది. ఇది గ్లిఫ్స్కు క్రింద ఉండే ఒక గ్రాఫికల్ ఎలిమెంట్ మాత్రమే, cmapలో నిల్వ చేయబడిన క్యారెక్టర్ ఆట్రిబ్యూట్ కాదు.
This distinction matters because no amount of font descriptor reading will reveal an underline. You need to look at the raw drawing operators on the page, or at the geometry-level output, for short horizontal line segments that run parallel to the baseline at the correct proximity. When your extraction engine spots such a segment underneath a text run, you tag that run as underlined. Treating this as a separate detection layer keeps your data model honest: bold and italic are intrinsic to the font, while underline is extrinsic decoration rendered by the document.
A Working Pipeline
A clean extraction system separates concerns into distinct layers. First, a geometry worker walks the page. It queries page.commonObjs to assemble your fontStyleMap, inspects each text item’s transform array to catch synthetic italics, and scans nearby vector paths to spot underlines. Its output is a clean intermediate structure call it textMeta where every text run carries three simple booleans: bold, italic, and underline.
Next, a text rebuilder consumes that structure and emits marked-up output. Nesting order is important here. The correct hierarchy places underline outermost, then italic, then bold innermost. That means a fully styled run becomes <u><i><b>text</b></i></u>. This ordering prevents invalid HTML overlaps and keeps rendering consistent across browsers and document converters. It also mirrors the typographic logic: decoration wraps semantic emphasis, and semantic emphasis wraps structural weight.
The power of this approach is that it uses only what the PDF already knows about itself. There is no OCR involved, no cloud vision service, and no machine learning model guessing at styles from rasterized pixels. You are reading the file’s own semantic layer, exposed through the geometry and metadata that the creator application already calculated. The result is fast, deterministic, and accurate across the chaotic landscape of PDF generators.
The Real Takeaway
Regex against font names is a trap. It feels like a shortcut because it works on the one file you tested, but it collapses under the mild pressure of a second export. The real information is already inside the PDF, sitting in descriptors, matrices, and vector paths. Build your pipeline around those facts. Ask the font object whether it is bold. Check the transform matrix for shear. Look at the drawn segments for underlines. If you query the document’s own engineering instead of scraping its surface labels, you get styles that survive from one PDF generator to the next.