نوری نستعلیق کرننگ پر کام!

arifkarim

معطل
GraphicsPath.AddString پھر FillPath
چونکہ یہ ایک ڈویلپمنٹ پراجیکٹ ہے، اسلئے جس حد تک ممکن ہو، اپنے سافٹوئیر کے کوڈ کو دیگر ڈویلپرز کے ساتھ شیئر کرتے رہیں۔ اگر پبلک میں کرنا ممکن نہ ہو تو ذاتی پیغام میں کر لیں۔ میری بھی یہی کوشش ہوگی کہ جمیل نوری نستعلیق کا سورس کوڈ ضرورت پڑنے پر ڈویلپمنٹ ٹیم کو الاٹ کر دیا جائے۔

ویسے جمیل نوری کا لیٹسٹ ورژن انسٹال کرنے کے بعدXP پر یہ مسئلہ حل ہو گیا ہے البتہ ونڈوز 7 پر فونٹ کشیدہ دکھائی دینا شروع ہو گیا ہے۔اور ونڈوز 7 پر لگیچرز صحیح رینڈر نہیں ہورہے۔
یہ کیا معمہ ہے!
یہ معمہ اس زمانہ کی کچھ "بونگیوں" کا سرچشمہ ہے جب فانٹ میکنگ میں ہم جگاڑ لگایا کرتے تھے۔ بہرحال اسکا فی الفور حل یہی ہے کہ Jameel Noori Nastaleeq Regular فانٹ کو چھوڑ کر اس کے باقی تمام ورژنز ان انسٹال کر دئے جائیں۔
 

mohdumar

محفلین
پروف آف کاسنیپٹ ہی کہہ لیں کہ اس قسم کے الگورتھم کے کمانڈ لائن ورژن اچھے نتائج دے سکتے ہیں۔ ملاحظہ ہو سکرین شاٹ۔ گرافکل پروگرام کے مقابلے میں رفتار چوگنی ہو گئی ہے۔ :)
ogzlQFX.png
 
آخری تدوین:

arifkarim

معطل
ابھی تک جو ہم تجربات کر رہے ہیں وہ وولٹ میں Pair Adjustment کیساتھ کرننگ کے ہیں۔ جسکا کوڈ کچھ اس قسم کا ہے:

کوڈ:
DEF_LOOKUP "kern0" PROCESS_BASE PROCESS_MARKS ALL DIRECTION RTL

IN_CONTEXT

END_CONTEXT

AS_POSITION

ADJUST_PAIR

FIRST  GLYPH "zeh" FIRST  GLYPH "reh"

SECOND  GLYPH "heh" SECOND  GLYPH "yeh" SECOND  GLYPH "dal"

1 1 BY POS END_POS POS ADV -200 END_POS

1 2 BY POS END_POS POS ADV -300 END_POS

1 3 BY POS END_POS POS ADV -250 END_POS

END_ADJUST

END_POSITION

END

البتہ وولٹ میں کرننگ کا ایک اور طریقہ Single Adjustment بھی ہے۔ یہ عموماً گروپ کرننگ یا کلاس کرننگ کیلئے استعمال ہوتا ہے۔ اگر ہمارے پاس پیئرز کی ایکزیکٹ کرننگ ویلیو ز نہ بھی ہوں ، تب بھی اس طریقہ سے بہت حد تک درست کرننگ حاصل ہو جاتی ہے۔ اسکے لئے ہمیں نوری نستعلیق کے تمام ترسیموں کی ابتدائی اور اختتامی اونچائی درکار ہوگی۔ یوں ہم مثال کے طور پر منفی 100 پکسل سے لیکر منفی 1000 پکسل تک تمام ترسیمہ جات کو کرننگ دے سکتے ہیں۔ ذیل میں ہم نے تین ترسیموں ’’کر‘‘ ’’کز‘‘ ’’سن‘‘ کو اس طریقہ سے کرن کیا ہے:
b642.gif

b644.gif

b643.gif

ایکسل اسپریڈشیٹ میں ان ویلیوز کو پلاٹ کرنے کے بعد یہ نتیجہ نکلتا ہے:
b645.gif

اس کو پڑھنے کا طریقہ:
اوپر آپ دیکھ سکتے ہیں کہ "سن" ترسیمے کی دائیں اسکیل سے -100 پر اونچائی 931 ہے۔ یعنی "کر" اور "کز" میں اسکے قریب ترین جو اونچائی ہو گی ہمیں اسے اتنا ہی کرن کرنا ہوگا۔ جیسے "کز" میں قریب ترین 973 ہے ، سو اس حساب سے "سن" کی "کز" کیساتھ کرننگ ویلیو -300 ہوئی۔
اسی طرح "کر" میں اسکے قریب ترین 701 ہے یوں اسکی کرننگ ویلیو -800 ہونی چاہئے۔ البتہ آپ بائیں جانب دیکھ سکتے ہیں کہ -800 پر "سن" بیس لائن سے نیچے چلا جاتا ہے، مطلب "کر" کا اختتام جو کہ بیس لائن سے اوپر ہے، سے یہ اس ویلیو پر ٹکرائے گا۔ یوں اسکی بجائے -700 والی ویلیو اسکے لئے زیادہ موذوں ہے۔ اسکی بنیاد پر ہم نے یہ 7 Single Adjustment کرننگ ٹیبلز بنا کر وولٹ میں امپورٹ کر لیے جس میں ہر ٹیبل کو -100 کرننگ ویلیو دی گئی ہے:
کوڈ:
DEF_LOOKUP "kern1" PROCESS_BASE PROCESS_MARKS ALL DIRECTION RTL
IN_CONTEXT
LEFT GLYPH "kr"
END_CONTEXT
IN_CONTEXT
LEFT GLYPH "kz"
END_CONTEXT
AS_POSITION
ADJUST_SINGLE GLYPH "sn" BY POS ADV -100 END_POS
END_ADJUST
END_POSITION
DEF_LOOKUP "kern2" PROCESS_BASE PROCESS_MARKS ALL DIRECTION RTL
IN_CONTEXT
LEFT GLYPH "kr"
END_CONTEXT
IN_CONTEXT
LEFT GLYPH "kz"
END_CONTEXT
AS_POSITION
ADJUST_SINGLE GLYPH "sn" BY POS ADV -100 END_POS
END_ADJUST
END_POSITION
DEF_LOOKUP "kern3" PROCESS_BASE PROCESS_MARKS ALL DIRECTION RTL
IN_CONTEXT
LEFT GLYPH "kr"
END_CONTEXT
IN_CONTEXT
LEFT GLYPH "kz"
END_CONTEXT
AS_POSITION
ADJUST_SINGLE GLYPH "sn" BY POS ADV -100 END_POS
END_ADJUST
END_POSITION
DEF_LOOKUP "kern4" PROCESS_BASE PROCESS_MARKS ALL DIRECTION RTL
IN_CONTEXT
LEFT GLYPH "kr"
END_CONTEXT
AS_POSITION
ADJUST_SINGLE GLYPH "sn" BY POS ADV -100 END_POS
END_ADJUST
END_POSITION
DEF_LOOKUP "kern5" PROCESS_BASE PROCESS_MARKS ALL DIRECTION RTL
IN_CONTEXT
LEFT GLYPH "kr"
END_CONTEXT
AS_POSITION
ADJUST_SINGLE GLYPH "sn" BY POS ADV -100 END_POS
END_ADJUST
END_POSITION
DEF_LOOKUP "kern6" PROCESS_BASE PROCESS_MARKS ALL DIRECTION RTL
IN_CONTEXT
LEFT GLYPH "kr"
END_CONTEXT
AS_POSITION
ADJUST_SINGLE GLYPH "sn" BY POS ADV -100 END_POS
END_ADJUST
END_POSITION
DEF_LOOKUP "kern7" PROCESS_BASE PROCESS_MARKS ALL DIRECTION RTL
IN_CONTEXT
LEFT GLYPH "kr"
END_CONTEXT
AS_POSITION
ADJUST_SINGLE GLYPH "sn" BY POS ADV -100 END_POS
END_ADJUST
END_POSITION
END
فانٹ کمپائلیشن کے بعد ورڈ میں نتیجہ:
b646.gif

یہ طریقہ اس لحاظ سے بہتر ہے کہ اسمیں 24000 × 10 یعنی زیادہ سے زیادہ 2 لاکھ 40 ہزار پیئرز کیساتھ سارا فانٹ کرن ہو سکتا ہے۔ گو کہ نتائج Pair Adjustment جتنے بہترین نہیں ہوں گے البتہ اگر یہ کسی وجہ سے کامیاب نہیں رہتا تو اسکا متبادل گروپ کرننگ کی شکل میں بہرحال موجود ہے۔ نیز اسکے استعمال کے بعد کرننگ پیئرز ہمیں خود نہیں بنانے پڑیں گے بلکہ کمپیوٹوشنلی یہ کام خودکار طور پر الگوردھمز کیساتھ رولز کی مدد سے ہو سکے گا۔ اسکی ایک اورخوبی یہ بھی ہے کہ اسکے ذریعہ اسپیس کیساتھ کرننگ سیٹ کرنا بھی ممکن ہے۔ اب اسکو میس آٹومیٹ کیسے کیا جائے ، اسکا جواب میں کوڈنگ اور امیج پراسیسنگ کے ماہرین کیلئے چھوڑتا ہوں۔
نبیل ابن سعید زیک رانا ابرارحسین عباس اعوان mohdumar
 
مدیر کی آخری تدوین:

mohdumar

محفلین
ابھی تک جو ہم تجربات کر رہے ہیں وہ وولٹ میں Pair Adjustment کیساتھ کرننگ کے ہیں۔ جسکا کوڈ کچھ اس قسم کا ہے:

کوڈ:
DEF_LOOKUP "kern0" PROCESS_BASE PROCESS_MARKS ALL DIRECTION RTL

IN_CONTEXT

END_CONTEXT

AS_POSITION

ADJUST_PAIR

FIRST  GLYPH "zeh" FIRST  GLYPH "reh"

SECOND  GLYPH "heh" SECOND  GLYPH "yeh" SECOND  GLYPH "dal"

1 1 BY POS END_POS POS ADV -200 END_POS

1 2 BY POS END_POS POS ADV -300 END_POS

1 3 BY POS END_POS POS ADV -250 END_POS

END_ADJUST

END_POSITION

END

البتہ وولٹ میں کرننگ کا ایک اور طریقہ Single Adjustment بھی ہے۔ یہ عموماً گروپ کرننگ یا کلاس کرننگ کیلئے استعمال ہوتا ہے۔ اگر ہمارے پاس پیئرز کی ایکزیکٹ کرننگ ویلیو ز نہ بھی ہوں ، تب بھی اس طریقہ سے بہت حد تک درست کرننگ حاصل ہو جاتی ہے۔ اسکے لئے ہمیں نوری نستعلیق کے تمام ترسیموں کی ابتدائی اور اختتامی اونچائی درکار ہوگی۔ یوں ہم مثال کے طور پر منفی 100 پکسل سے لیکر منفی 1000 پکسل تک تمام ترسیمہ جات کو کرننگ دے سکتے ہیں۔ ذیل میں ہم نے تین ترسیموں ’’کر‘‘ ’’کز‘‘ ’’سن‘‘ کو اس طریقہ سے کرن کیا ہے:
b642.gif

b644.gif

b643.gif

ایکسل اسپریڈشیٹ میں ان ویلیوز کو پلاٹ کرنے کے بعد یہ نتیجہ نکلتا ہے:
b645.gif

اس کو پڑھنے کا طریقہ:
اوپر آپ دیکھ سکتے ہیں کہ "سن" ترسیمے کی دائیں اسکیل سے -100 پر اونچائی 931 ہے۔ یعنی "کر" اور "کز" میں اسکے قریب ترین جو اونچائی ہو گی ہمیں اسے اتنا ہی کرن کرنا ہوگا۔ جیسے "کز" میں قریب ترین 973 ہے ، سو اس حساب سے "سن" کی "کز" کیساتھ کرننگ ویلیو -300 ہوئی۔
اسی طرح "کر" میں اسکے قریب ترین 701 ہے یوں اسکی کرننگ ویلیو -800 ہونی چاہئے۔ البتہ آپ بائیں جانب دیکھ سکتے ہیں کہ -800 پر "سن" بیس لائن سے نیچے چلا جاتا ہے، مطلب "کر" کا اختتام جو کہ بیس لائن سے اوپر ہے، سے یہ اس ویلیو پر ٹکرائے گا۔ یوں اسکی بجائے -700 والی ویلیو اسکے لئے زیادہ موذوں ہے۔ اسکی بنیاد پر ہم نے یہ 7 Single Adjustment کرننگ ٹیبلز بنا کر وولٹ میں امپورٹ کر لیے جس میں ہر ٹیبل کو -100 کرننگ ویلیو دی گئی ہے:
کوڈ:
DEF_LOOKUP "kern1" PROCESS_BASE PROCESS_MARKS ALL DIRECTION RTL
IN_CONTEXT
LEFT GLYPH "kr"
END_CONTEXT
IN_CONTEXT
LEFT GLYPH "kz"
END_CONTEXT
AS_POSITION
ADJUST_SINGLE GLYPH "sn" BY POS ADV -100 END_POS
END_ADJUST
END_POSITION
DEF_LOOKUP "kern2" PROCESS_BASE PROCESS_MARKS ALL DIRECTION RTL
IN_CONTEXT
LEFT GLYPH "kr"
END_CONTEXT
IN_CONTEXT
LEFT GLYPH "kz"
END_CONTEXT
AS_POSITION
ADJUST_SINGLE GLYPH "sn" BY POS ADV -100 END_POS
END_ADJUST
END_POSITION
DEF_LOOKUP "kern3" PROCESS_BASE PROCESS_MARKS ALL DIRECTION RTL
IN_CONTEXT
LEFT GLYPH "kr"
END_CONTEXT
IN_CONTEXT
LEFT GLYPH "kz"
END_CONTEXT
AS_POSITION
ADJUST_SINGLE GLYPH "sn" BY POS ADV -100 END_POS
END_ADJUST
END_POSITION
DEF_LOOKUP "kern4" PROCESS_BASE PROCESS_MARKS ALL DIRECTION RTL
IN_CONTEXT
LEFT GLYPH "kr"
END_CONTEXT
AS_POSITION
ADJUST_SINGLE GLYPH "sn" BY POS ADV -100 END_POS
END_ADJUST
END_POSITION
DEF_LOOKUP "kern5" PROCESS_BASE PROCESS_MARKS ALL DIRECTION RTL
IN_CONTEXT
LEFT GLYPH "kr"
END_CONTEXT
AS_POSITION
ADJUST_SINGLE GLYPH "sn" BY POS ADV -100 END_POS
END_ADJUST
END_POSITION
DEF_LOOKUP "kern6" PROCESS_BASE PROCESS_MARKS ALL DIRECTION RTL
IN_CONTEXT
LEFT GLYPH "kr"
END_CONTEXT
AS_POSITION
ADJUST_SINGLE GLYPH "sn" BY POS ADV -100 END_POS
END_ADJUST
END_POSITION
DEF_LOOKUP "kern7" PROCESS_BASE PROCESS_MARKS ALL DIRECTION RTL
IN_CONTEXT
LEFT GLYPH "kr"
END_CONTEXT
AS_POSITION
ADJUST_SINGLE GLYPH "sn" BY POS ADV -100 END_POS
END_ADJUST
END_POSITION
END
فانٹ کمپائلیشن کے بعد ورڈ میں نتیجہ:
b646.gif

یہ طریقہ اس لحاظ سے بہتر ہے کہ اسمیں 24000 × 10 یعنی زیادہ سے زیادہ 2 لاکھ 40 ہزار پیئرز کیساتھ سارا فانٹ کرن ہو سکتا ہے۔ گو کہ نتائج Pair Adjustment جتنے بہترین نہیں ہوں گے البتہ اگر یہ کسی وجہ سے کامیاب نہیں رہتا تو اسکا متبادل گروپ کرننگ کی شکل میں بہرحال موجود ہے۔ نیز اسکے استعمال کے بعد کرننگ پیئرز ہمیں خود نہیں بنانے پڑیں گے بلکہ کمپیوٹوشنلی یہ کام خودکار طور پر الگوردھمز کیساتھ رولز کی مدد سے ہو سکے گا۔ اسکی ایک اورخوبی یہ بھی ہے کہ اسکے ذریعہ اسپیس کیساتھ کرننگ سیٹ کرنا بھی ممکن ہے۔ اب اسکو میس آٹومیٹ کیسے کیا جائے ، اسکا جواب میں کوڈنگ اور امیج پراسیسنگ کے ماہرین کیلئے چھوڑتا ہوں۔
نبیل ابن سعید زیک رانا ابرارحسین عباس اعوان mohdumar

عارف بھائی! یقیناً آپ وولٹ کے معاملوں میں اتھارٹی ہیں اس میں کوئی شبہ نہیں!
لیکن میری رائے میں سنگل ایڈجسٹمنٹ میں بھی مسئلہ برقرار ہے کہ ترسیموں کے درمیان کتنی کرننگ رکھی جائے اور کس طریقے سے اخذ کی جائے۔ لیکن پھر بھی آپ نے پیئر کی نسبت سنگل ایڈجسٹمنٹ کے جو فوائد بیان کیے ہیں خصوصاً الفاظ کے مابین کرننگ ان کو دیکھتے ہوئے ہم کرننگ الگورتھمز کی آوٹ پٹ سنگل ایڈجسٹمنٹ کی طرف ڈھال سکتے ہیں۔:)
 
مدیر کی آخری تدوین:

arifkarim

معطل
لیکن پھر بھی آپ نے پیئر کی نسبت سنگل ایڈجسٹمنٹ کے جو فوائد بیان کیے ہیں خصوصاً الفاظ کے مابین کرننگ ان کو دیکھتے ہوئے ہم کرننگ الگورتھمز کی آوٹ پٹ سنگل ایڈجسٹمنٹ کی طرف ڈھال سکتے ہیں۔
الفاظ کے مابین کرننگ کوئی بہت بڑا ایشو نہیں ہے۔ جب درمیان میں صرف اسپیس آ رہی ہو تو اوپر موجود سنگل ایڈجسٹمنٹ ٹیبل کو اسطرح ری رائٹ کر دیں:
کوڈ:
DEF_LOOKUP "kern1" PROCESS_BASE PROCESS_MARKS ALL DIRECTION RTL
IN_CONTEXT
LEFT GLYPH "kr"
RIGHT GLYPH "sn"
END_CONTEXT
AS_POSITION
ADJUST_SINGLE GLYPH "space" BY POS ADV -100END_POS
END_ADJUST
END_POSITION
END
نتیجتاً اسپیس کیساتھ بھی ہو بہو وہی کرننگ حاصل ہو جائے گی جو بغیر اسپیس کے چل رہی ہے۔ غالباً مئی یا جون میں میری زیک بھائی سے اس سلسلہ میں کافی مشاورت رہی ہے ۔ آپکے مطابق تمام ترسیمہ جات کی اونچائی خودکار طور پر معلوم کرنا یقیناً ممکن ہے۔ جب تک ہم الفاظ کے اندر کرننگ کا عمل مکمل کر کے فارغ ہوں گے، تب تک گروپ کرننگ یعنی اسپیس کرننگ کا رزلٹ بھی انشاءاللہ آ چکا ہوگا۔
اسکا بنیادی ڈھانچہ کچھ ایسا ہوگا کہ ہم سعود بھائی کے ترسیمہ لسٹ سارٹر کی مدد سے تمام ترسیموں کو انکی اخیر کے حساب سے سارٹ کریں گے۔ اور پھر انہیں الگ الگ ٹیبلز میں ڈال کر یکمشت کرننگ اپلائی کریں گے۔ جیسے ی،ن،ص،ل،ق وغیرہ کی اختتامی شکل قریباً ایک جیسی ہے تو یہ ایک ہی گروپ میں آجائیں گے۔ پھر ہم زیک بھائی کے فراہم کر دہ ہائٹ ڈیٹا کی مدد سے ان تمام ترسیموں کو جو اس گروپ کی اختتامی اشکال سے زیادہ بلند ہیں کو ایک اوسط کرننگ ویلیو کیساتھ ڈیفائن کردیں گے۔ چونکہ یہ گروپ کرننگ ہوگی، یوں یہ پورے فانٹ میں ہر وقت فعال ہوگی اور Pair Adjustment کی کمزوریاں اسمیں موجود نہیں ہوں گی۔
 

mohdumar

محفلین
چونکہ یہ ایک ڈویلپمنٹ پراجیکٹ ہے، اسلئے جس حد تک ممکن ہو، اپنے سافٹوئیر کے کوڈ کو دیگر ڈویلپرز کے ساتھ شیئر کرتے رہیں۔ اگر پبلک میں کرنا ممکن نہ ہو تو ذاتی پیغام میں کر لیں۔

کمانڈ لائن ٹول کا کوڈ ان روابط سے حاصل کیا جا سکتا ہے۔ محفلینز سے گزارش ہے کہ پُوَر پروگریمنگ پریکٹسز پر ہمیں نہ کوسا جائے۔ :)

Code.vb
Code.pdf
Metrics.afm
 

mohdumar

محفلین
اپڈیٹس:
کل ہم نے اپنے پروگرام میں کچھ تبدیلیاں کیں، خصوصاََ فونٹ سائز کو 144px سے نصف کر کے 72px کر دیا اور سٹروک چوڑائی بھی کم کر دی۔
اس سے یہ ہوا کہ امیج پروسیسنگ راکٹ کی طرح تیز ہوگئی اور ہم نے چند سیکنڈوں میں نعیم سعید کی لگیچر لسٹ سے تقریباََ سات سو پیئر پروسیس کرلئے۔ اس کا یہ بھی مطلب ہے کہ نعیم بھائی کی 50000 مستند پیئرز کی لسٹ پروسیس کرنا منٹوں کا کام ہے۔ وہ الگ بات ہے کہ فالحال ہم سنگل ایڈجسٹمنٹ کی بجائے پیئر ہی استعمال کر رہے ہیں، کیونکہ الفاظ کے اندر ہی کی کرننگ کا تجربہ کیا جارہا تھا۔
Of228ez.png


نتائج کو وولٹ میں درآمد کرنے کے بعد فونٹ کو کمپائل کیا اور مائکروسوفٹ ورڈ میں استعمال کیا۔ اس کے نتائج اس ربط پر دیکھ لیں۔
ورڈ میں جن الفاظ کی کرننگ خراب لگ رہی تھی، ہم نے انھی کو ان پیج میں بھی درج کر کے دیکھا تو معلوم ہوا ان پیج میں بھی بالکل وہی خرابی ہے۔ اس سے عارف بھائی کا وہ مشاہدہ سچ ثابت ہو گیا کہ ان پیج سٹروک کرننگ ہی استعمال کرتا ہے۔ :)
 

mohdumar

محفلین
الفاظ کے مابین کرننگ کوئی بہت بڑا ایشو نہیں ہے۔ جب درمیان میں صرف اسپیس آ رہی ہو تو اوپر موجود سنگل ایڈجسٹمنٹ ٹیبل کو اسطرح ری رائٹ کر دیں:
برائے کرم اس کا عملی تجربہ کر دیں۔

نیز جمیل نوری میں نقاظ کی پلیسمنٹ کے بارے میں بھی بتا دیں جو کہ کرننگ خراب کرتی ہے۔
IlzzsPH.png
 

arifkarim

معطل
برائے کرم اس کا عملی تجربہ کر دیں۔
میں نے اوپر جو کوڈ دیا ہے اسپیس کیساتھ، اسکو وولٹ میں امپورٹ کر کے دیکھ لیں۔

نیز جمیل نوری میں نقاظ کی پلیسمنٹ کے بارے میں بھی بتا دیں جو کہ کرننگ خراب کرتی ہے۔
یہ مسئلہ نہیں ہے کیونکہ انپیج 3 کے بعد سے "یر" کو ایسے ہی فانٹ میں شامل کیا گیا ہے۔ اس سے سابق ورژنز میں اسکے نکتے ویسے ہی تھے جیسا کہ آپنے اوپر تصویر میں دکھائے ہیں۔
 

arifkarim

معطل
کل ہم نے اپنے پروگرام میں کچھ تبدیلیاں کیں، خصوصاََ فونٹ سائز کو 144px سے نصف کر کے 72px کر دیا اور سٹروک چوڑائی بھی کم کر دی۔
مجھے تجسس ہے کہ پکسل سائز کم کرنے سے پروسیسنگ کی رفتار میں بہتری کیسے ہوئی ہے؟ کہیں ایسا تو نہیں کہ ایسا کرنے سے امیج پراسیسنگ ڈیٹا کم ہو جاتا ہے اور یوں رفتار بہت تیز ہو جاتی ہے؟

نتائج کو وولٹ میں درآمد کرنے کے بعد فونٹ کو کمپائل کیا اور مائکروسوفٹ ورڈ میں استعمال کیا۔ اس کے نتائج اس ربط پر دیکھ لیں۔
نتائج تسلی بخش ہیں۔ بہت خوب! اب کم از کم ایک پیئر کے مابین خودکار کرننگ مسئلہ نہیں رہا۔
لیکن چونکہ بہت سے الفاظ میں کرننگ پیئرز ایک سے زیادہ ہوتے ہیں، انکو کیسے پراسیس کروایا جائے، یہ کام ابھی کرنا باقی ہے۔ :thinking:

ورڈ میں جن الفاظ کی کرننگ خراب لگ رہی تھی، ہم نے انھی کو ان پیج میں بھی درج کر کے دیکھا تو معلوم ہوا ان پیج میں بھی بالکل وہی خرابی ہے۔ اس سے عارف بھائی کا وہ مشاہدہ سچ ثابت ہو گیا کہ ان پیج سٹروک کرننگ ہی استعمال کرتا ہے۔ :)
خیر یہ صرف میرا مشاہدہ نہیں تھا۔ بہرحال اگر آپ اسٹروک سائز بہت کم یا صفر کر دیں تو جہاں خراب کرننگ آ رہی ہے، وہاں بھی بہتری لائی جا سکتی ہے۔
 
مجھے تجسس ہے کہ پکسل سائز کم کرنے سے پروسیسنگ کی رفتار میں بہتری کیسے ہوئی ہے؟ کہیں ایسا تو نہیں کہ ایسا کرنے سے امیج پراسیسنگ ڈیٹا کم ہو جاتا ہے اور یوں رفتار بہت تیز ہو جاتی ہے؟
فونٹ سائز کم کرنے سے حاصل شدہ راسٹر امیج میں پکسلز کی تعداد کم ہو جاتی ہے، نتیجتاً دو دو پکسلز کے جوڑوں کی تعداد کم ہو جاتی ہے جن کے ما بین فاصلہ معلوم کرنا مقصود ہوتا ہے۔ ہمارا اندازہ ہے کہ یہ نسبت تقریباً چار کی قوت والی ہونی چاہیے۔ اگر اس کی اپر باؤنڈ انالسس کریں تو بات کچھ یوں بنے گی:

تصور کریں کہ راسٹر امیج کی صورت دو ترسیمے یکے بعد دیگرے لکھے گئے ہیں جن کے ما بین کم سے کم فاصلہ حاصل کرنا ہے۔ مان لیں کہ دونوں ہی ترسیمے علیحدہ علیحدہ 200 سیاہ پکسلز پر مشتمل ہیں۔ اگر پہلے ترسیمے کے تمام سیاہ پکسلز کا فاصلہ دوسرے ترسیمے کے تمام پکسلز کے ساتھ نکالا جائے تو ہر 200 پکسل کو دیگر 200 پکسلز کے ساتھ پراسیس کرنا پڑے گا یعنی مجموعی موازنوں کی تعداد 200×200 (40000) ہوگی جو کہ ایک ترسیمے کی پکسلز کے تعداد کا مربع ہے۔ اور اگر ہمارا یہ مفروضہ درست ہے کہ فونٹ سائز نصف کرنے سے ترسیمے کی لمبائی اور اونچائی دونوں نصف ہو جاتی ہیں تو ان کا رقبہ ایک چوتھائی ہو جائے گا، نتیجتاً سیاہ پکسلز کی تعداد پہلے کی ایک چوتھائی رہ جائے گی۔ یعنی سیاہ پکسلز کی تعداد فونٹ سائز سے مربع کی نسبت رکھتا ہے۔ یوں ہمارے مفروضہ امیج میں فقط تمام 50 پکسلز کا دیگر ترسیمے کے تمام 50 پکسلز کے ساتھ موازنہ کرنا پڑے گا جن کی تعداد 50×50 (2500) ہوگی۔ یوں معلوم ہوتا ہے کہ فونٹ سائز دو گنا کرنے پر پکسل کے موازنوں کی تعداد 2 پر چار کی قوت یعنی 16 گنا بڑھ جائے گی۔ :) :) :)
 

mohdumar

محفلین
مجھے تجسس ہے کہ پکسل سائز کم کرنے سے پروسیسنگ کی رفتار میں بہتری کیسے ہوئی ہے؟ کہیں ایسا تو نہیں کہ ایسا کرنے سے امیج پراسیسنگ ڈیٹا کم ہو جاتا ہے اور یوں رفتار بہت تیز ہو جاتی ہے؟
جی آپ ٹھیک سمجھے۔ ہم نے فونٹ سائز تو چھوٹا کر دیا ساتھ ساتھ اپنی وولٹ والی جگاڑ بھی اسی حساب سے تبدیل کی۔البتہ چھوٹے سائز پر سٹروک کھینچو تو کچھ لگیچرز پر GDI انجن عجیب حرکتیں شروع کر دیتا ہے۔ اس کا حل ہمیں حسن اتفاق سے مل گیا۔ بس سٹروک کھینچے والے pen کی پراپرٹیز بدلنا پڑیں۔

بہرحال اگر آپ اسٹروک سائز بہت کم یا صفر کر دیں تو جہاں خراب کرننگ آ رہی ہے، وہاں بھی بہتری لائی جا سکتی ہے۔
اس کے لئے انفرادی طور پر پیئرز کی نشاندہی کرنا ہوگی۔ ابھی تک تو 'سرین' اور 'زیر' جیسے پیئر ہی مسئلہ کر رہے ہیں۔

نیز وولٹ میں spaces والا کوڈ کمپائل ہونے کے باوجود کوئی کام نہیں کر رہا ۔ یقینا ہم نے کچھ گڑ بڑ کی ہے۔ رہنمائی کریں۔
 

mohdumar

محفلین
فونٹ سائز کم کرنے سے حاصل شدہ راسٹر امیج میں پکسلز کی تعداد کم ہو جاتی ہے، نتیجتاً دو دو پکسلز کے جوڑوں کی تعداد کم ہو جاتی ہے جن کے ما بین فاصلہ معلوم کرنا مقصود ہوتا ہے۔ ہمارا اندازہ ہے کہ یہ نسبت تقریباً چار کی قوت والی ہونی چاہیے۔ اگر اس کی اپر باؤنڈ انالسس کریں تو بات کچھ یوں بنے گی:

تصور کریں کہ راسٹر امیج کی صورت دو ترسیمے یکے بعد دیگرے لکھے گئے ہیں جن کے ما بین کم سے کم فاصلہ حاصل کرنا ہے۔ مان لیں کہ دونوں ہی ترسیمے علیحدہ علیحدہ 200 سیاہ پکسلز پر مشتمل ہیں۔ اگر پہلے ترسیمے کے تمام سیاہ پکسلز کا فاصلہ دوسرے ترسیمے کے تمام پکسلز کے ساتھ نکالا جائے تو ہر 200 پکسل کو دیگر 200 پکسلز کے ساتھ پراسیس کرنا پڑے گا یعنی مجموعی موازنوں کی تعداد 200×200 (40000) ہوگی جو کہ ایک ترسیمے کی پکسلز کے تعداد کا مربع ہے۔ اور اگر ہمارا یہ مفروضہ درست ہے کہ فونٹ سائز نصف کرنے سے ترسیمے کی لمبائی اور اونچائی دونوں نصف ہو جاتی ہیں تو ان کا رقبہ ایک چوتھائی ہو جائے گا، نتیجتاً سیاہ پکسلز کی تعداد پہلے کی ایک چوتھائی رہ جائے گی۔ یعنی سیاہ پکسلز کی تعداد فونٹ سائز سے مربع کی نسبت رکھتا ہے۔ یوں ہمارے مفروضہ امیج میں فقط تمام 50 پکسلز کا دیگر ترسیمے کے تمام 50 پکسلز کے ساتھ موازنہ کرنا پڑے گا جن کی تعداد 50×50 (2500) ہوگی۔ یوں معلوم ہوتا ہے کہ فونٹ سائز دو گنا کرنے پر پکسل کے موازنوں کی تعداد 2 پر چار کی قوت یعنی 16 گنا بڑھ جائے گی۔ :) :) :)

جی بالکل ۔ ہم نے جب سابقہ اور نئے ریٹس کا موازنہ کیا تو نیا پرانے کا چوگنا ہی تھا۔ یہ دیکھتے ہوئے ہم بالکل آپ ہی کے نتیجے پر پہنچے تھے۔
 

arifkarim

معطل
نیز وولٹ میں spaces والا کوڈ کمپائل ہونے کے باوجود کوئی کام نہیں کر رہا ۔ یقینا ہم نے کچھ گڑ بڑ کی ہے۔ رہنمائی کریں۔
وولٹ میں ccmp ٹیبل ہوگا جہاں اسپیس کیریکٹر کسی اور گلف کیساتھ سبسٹیٹیوٹ ہو رہا ہے۔ اس ٹیبل کو کمپائیلیشن ونڈو سے ڈی لنک کر دیں۔ امید ہے افاقہ ہو گا :)
 

arifkarim

معطل
یوں معلوم ہوتا ہے کہ فونٹ سائز دو گنا کرنے پر پکسل کے موازنوں کی تعداد 2 پر چار کی قوت یعنی 16 گنا بڑھ جائے گی۔ :) :) :)

جی بالکل ۔ ہم نے جب سابقہ اور نئے ریٹس کا موازنہ کیا تو نیا پرانے کا چوگنا ہی تھا۔ یہ دیکھتے ہوئے ہم بالکل آپ ہی کے نتیجے پر پہنچے تھے۔

اسکا مطلب ایک ایسا معقول فانٹ سائز ڈھونڈنا ہوگا جو ہمیں متوقع کرننگ ویلیو بھی دے اور پروسیسنگ رفتار پر نظر انداز بھی نہ ہو :)
 

mohdumar

محفلین
وولٹ میں ccmp ٹیبل ہوگا جہاں اسپیس کیریکٹر کسی اور گلف کیساتھ سبسٹیٹیوٹ ہو رہا ہے۔ اس ٹیبل کو کمپائیلیشن ونڈو سے ڈی لنک کر دیں۔ امید ہے افاقہ ہو گا :)
ڈی لنگ تو نہیں کیا البتہ ایک دفعہ glyph296 کو space کی جگہ لکھ کر تجربہ کیا تو وہ بھی فیل ہو گیا تھا۔
آپ یہ بتا دیں کہ space والے جدول کو پچھلے سات سنگل ایڈجسٹمنٹ ٹیبلز کی جگہ ڈالنا ہے یا پھر ان کے ساتھ؟
 

arifkarim

معطل
ڈی لنگ تو نہیں کیا البتہ ایک دفعہ glyph296 کو space کی جگہ لکھ کر تجربہ کیا تو وہ بھی فیل ہو گیا تھا۔
اسکو ڈی لنک کر دیں اور صرف اسپیس کو استعمال کریں۔

آپ یہ بتا دیں کہ space والے جدول کو پچھلے سات سنگل ایڈجسٹمنٹ ٹیبلز کی جگہ ڈالنا ہے یا پھر ان کے ساتھ؟
اسکے پیچھے منطق یہ ہے کہ بالفرض اگر ایک پیئر کی کرننگ ویلیو -300 ہے تو یہ پیئر تین جدول میں ظاہر ہوگا۔ نہ اس سے کم نہ زیادہ۔ اسی طرح باقی پیئرز کو بھی اسی طرح ڈیفائن کرنا ہوگا۔ کیونکہ اگر ہم سیدھا -300 کی ویلیو ایک ہی ٹیبل میں رکھ دیں گے اور کسی اور جدول میں یہ پیئر پھر آمنے سامنے آگئے تو نتائج کافی غیرمتوقع سے ظاہر ہوں گے۔ اسکا تجربہ ابن سعید بھائی کیساتھ ہم آڈیو ملاقات میں کر چکے ہیں :)
 
کمانڈ لائن ٹول کا کوڈ ان روابط سے حاصل کیا جا سکتا ہے۔ محفلینز سے گزارش ہے کہ پُوَر پروگریمنگ پریکٹسز پر ہمیں نہ کوسا جائے۔ :)

Code.vb
Code.pdf
Metrics.afm
ہم آپ کے کوڈ کا سرسری جائزہ لے رہے تھے تو محسوس کیا کہ اس میں آپٹیمائزیشن کی کافی گنجائش موجود ہے۔ چونکہ ہم ڈاٹ نیٹ فیملی کی پروگرامنگ زبانوں میں کوئی تجربہ نہیں رکھتے اس لیے براہ راست کوڈ میں تبدیلی نہیں کر رہے، البتہ جہاں تک ہم کوڈ کو سمجھ سکے ہیں اس کی بنیاد پر کچھ تجاویز دیتے ہیں۔ :) :) :)

ہم مثال کے طور پر آپ کے درج ذیل فنکشن کا جائزہ لیتے ہیں:
PHP:
Private Function MaxLeftAtY(ByRef jc As Color(,), ByVal y As Integer, ByRef objBitmap As Bitmap) As Integer

    Dim x As Integer = 0
    Dim maxx As Integer = 0
    Dim notext As Boolean = 1

    Dim retval As Integer = -1

    For x = 0 To objBitmap.Width - 1 Step 1
        If jc(x, y).A = 255 And jc(x, y).G >= 0 Then
            notext = False
            If x > maxx Then
                maxx = x
            End If
        Else
        End If
    Next

    If notext = True Then
    Else
        retval = maxx
    End If
    Return retval
End Function

ہمارا خیال ہے کہ آپ اس فنکشن میں کسی مخصوص اونچائی y پر موجود تمام پکسلز کی قطار میں سے سب سے بائیں جانب موجود سیاہ پکسل کو اخذ کرنا چاہتے ہیں۔ اور یہ فنکش غالباً دائیں جانب موجود ترسیمے کے لیے ہر ممکنہ y اونچائی کے لیے علیحدہ علیحدہ کال کیا جاتا ہوگا۔ اور اگر ہم درست سمجھے ہیں تو آپ اس مخصوص اونچائی y پر موجود تمام پکسلز کا یکے بعد دیگرے جائزہ لیتے ہیں۔ اگر ایسا ہے تو اس میں بہتری کی گنجائش موجود ہے، مثلاً کسی افقی قطار کو بائیں سے دائیں جانب اسکین کیا جائے تو جو پہلا سیاہ پکسل انکاؤنٹر ہو وہیں لوپ بریک کر کے اس قدر کو لوٹایا جا سکتا ہے، کیونکہ اس پکسل کے دائیں طرف جانے پر کوئی بہتر قدر سامنے نہیں آئے گی خواہ ماندہ پکسلز سیاہ ہوں خواہ سفید۔ بعینہ MinRightAtY کے لیے ہر افقی قطار کو دائیں سے بائیں جانب اسکین کیا جانا چاہیے تاکہ اولین سیاہ پکسل پر لوپ کو بریک کیا جا سکے۔ :) :) :)

ویسے x اور maxx کے موازنے کو دیکھ کر ہم نے محسوس کیا ہے کہ آپ کوڈ میں x کی قدر بڑھاتے ہوئے غالباً دائیں سے بائیں رخ پر جا رہے ہوتے ہیں، جبکہ عام مشاہدہ یہ ہے کہ کمپیوٹر گرافکس میں x کوآرڈینیٹ بائیں سے دائیں اور y کوآرڈینیٹ اوپر سے نیچے بڑھتے ہیں۔ کیا ایسی تبدیلی آپ نے کی ہے، یا پھر وی بی کی بٹ میپ لائبریری کا ایسا طریقہ کار ہے، یا پھر آر ٹی ایل موڈ سیٹ کرنے کا کوئی طریقہ کار موجود ہے، یا پھر ہم سے سمجھنے میں ہی کوئی نقص سرزد ہوا ہے؟ :) :) :)
 

arifkarim

معطل
ابن سعید
میں یہاں یہ جاننا چاہوں گا کہ جب ہمارے پاس تمام پیئرز کی کرننگ ویلیوز موجود ہوں تو کیا ہم انکو Single Adjustment کی بنیاد پر پارس کروا سکتے ہیں؟ اسطرح کے پروگرام مطلوبہ پیئر کی ایکزیکٹ کرننگ ویلیو اٹھائے او ر اسے قریب ترین 100ویں پکسل کے حساب سے سیٹ کر دے۔ اب اگر اسے پیئرکی کرننگ ویلیو -500 حاصل ہوئی تو اس پیئر کو پانچ ٹیبلز میں تقسیم کر دے جہا ں ہر ٹیبل کی کرننگ ویلیو -100 ڈیفائنڈ ہو۔ پھر یہی عمل ہر پیئر کے ساتھ دہرایا جائے۔ یوں تمام پیئرز اپنے لاجیکل ٹیبل میں پہنچ جائیں گے۔
اب ان ٹیبلز کو کمبائن کرنے کا عمل شروع کیا جائے۔ اور یہ خیال رکھا جائے کہ کم سے کم ٹیبلز میں زیادہ سے زیادہ کتنے پیئرز مطلوبہ کرننگ فراہم کر سکتے ہیں۔ چونکہ یہ گروپ کرننگ ہے یوں ایک ہی ٹیبل میں ہزاروں پیئرز آمنے سامنے با آسانی ایڈ کئے جا سکتے ہیں۔ البتہ شرط وہی ہونی چاہئے جسکا میں نے اوپر ذکر کیا ہے۔
 
Top