พี่เทพครับปรึกษาเรี่อง konsole หน่อยครับ
jakkapun kwanroengjai (Golf)
ถ้าเราจะเปลี่ยนไปใช้ painter.drawText(rect,text); แทน
และเปลี่ยนฟอนต์ที่ใช้ไปเป็นแบบ pseudo monospace (TlwgTypewriter) แทน
มันจะดีไหมครับ ?
else if ( style->rendition & RE_EXTENDED_CHAR ) //draw
CharSequence
drawCharSequence(painter,rect,text,style); -->
painter.drawText(rect,text);
Theppitak Karoonboonyanan
ต้องทดลองดูนะครับ ตามที่ผมเข้าใจ ฟอนต์พวกนี้
จะอ่าน IsFixedPitch ได้เป็น false และอาจเกิด dotted
circle ตอน render สระอำโดด ๆ ในเซลล์
ผมไม่มี KDE ให้ลองนะครับ ฝากลองละกัน
เทพ.
--
Theppitak Karoonboonyanan
http://linux.thai.net/~thep/
jakkapun kwanroengjai (Golf)
> จะอ่าน IsFixedPitch ได้เป็น false และอาจเกิด dotted
> circle ตอน render สระอำโดด ๆ ในเซลล์
>
> ผมไม่มี KDE ให้ลองนะครับ ฝากลองละกัน
TlwgTypewriter, Monospace และไม่เกิด dotted circle ครับ
และผมได้ทำ patch konsole ใหม่โดยตัดส่วน drawCharSequence ออกไปครับ
http://linux.thai.net/viewvc/viewvc.cgi/software/kde/kdebase-3.96.0/konsole_thai_patch.diff?view=log
พี่เทพครับ konsole ยังมีอะไรที่ต้องปรับแก้อีกหรือเปล่าครับ ?
ขอบคุณครับ
Theppitak Karoonboonyanan
> > จะอ่าน IsFixedPitch ได้เป็น false และอาจเกิด dotted
> > circle ตอน render สระอำโดด ๆ ในเซลล์
> >
> > ผมไม่มี KDE ให้ลองนะครับ ฝากลองละกัน
>
> ทดลองแล้วได้ผลว่ามันอ่าน fixedpitch เป็น true ครับ
อืม ชักงงว่า Qt ไปอ่านข้อมูลไหนของฟอนต์ขึ้นมา
เพราะใน AFM ของฟอนต์พวกนี้จะระบุชัดว่า
IsFixedPitch: false เป็นไปได้ว่าอาจเช็ก PFM family
ว่าเป็น Monospace หรือเปล่า อะไรเทือกนั้น
> ทดลองกับฟอนต์
> TlwgTypewriter, Monospace และไม่เกิด dotted circle ครับ
แล้วโค้ดเดียวกันนี้ render ได้ทั้ง TlwgTypewrite และ
TlwgMono เลยหรือเปล่า? พวกสระบน-ล่างและสระอำ
ออกมาเหมือนกันทั้งสองฟอนต์ไหม?
(ถ้าสระบน-ล่างออกมาเหมือนกันนี่ แสดงว่าต้องมี magic
อะไรบางอย่าง ในเมื่อมันไม่เห็นความแตกต่างของ IsFixedPitch
แต่ตัว metrics ของฟอนต์มันต่างกัน)
> และผมได้ทำ patch konsole ใหม่โดยตัดส่วน drawCharSequence ออกไปครับ
> http://linux.thai.net/viewvc/viewvc.cgi/software/kde/kdebase-3.96.0/konsole_thai_patch.diff?view=log
> พี่เทพครับ konsole ยังมีอะไรที่ต้องปรับแก้อีกหรือเปล่าครับ ?
เท่าที่จำได้ก็ไม่น่าจะมีนะครับ ยกเว้นข้อสงสัยข้างต้น
jakkapun kwanroengjai
> TlwgMono เลยหรือเปล่า? พวกสระบน-ล่างและสระอำ
> ออกมาเหมือนกันทั้งสองฟอนต์ไหม?
Theppitak Karoonboonyanan
โอเคครับ งั้นก็เข้าใจได้
แต่ก็เท่ากับว่า ตอนนี้เราล็อคฟอนต์ที่จะใช้ได้อยู่ที่ประเภทเดียว
คือ Pseudo-Mono คือจะ monospace ก็ไม่ได้ (เพราะสระบน-ล่าง
จะหาย) จะ proportional ก็ไม่ได้ (เพราะจะมีการแยกสระอำ
พร้อม dotted circle?)
ในทางเทคนิค ผมคิดว่ามันยังดูแปลก ๆ อยู่ดีน่ะ เพราะฟอนต์
pseudo-mono นี่ ไม่มีอยู่ใน spec ใด ๆ มีแต่ monospace
กับ proportional เท่านั้น
Pattara "Ott" Kiatisevi
ถ้าังั้นเหมือนว่าคำตอบสุดท้ายคือการแก้ให้ Qt draw text โดยใช้ Pure Mono (TlwgMono)
ได้ใช่ไหมครับ เืมื่อเป็นเช่นนั้น ปัญหาทั้งใน Konsole, Kate/Kwrite ก็จะถูกแก้หมดไปในคราวเดียว
ระหว่างนี้ก็ใช้ Pseudo mono ไปก่อนแก้ขัด?
ใน Gtk+/GNOME นี่ได้ทั้ง Pure/Pseudomono เลยป่าวครับ
Ott
> เทพ.
>
Theppitak Karoonboonyanan
> ถ้าังั้นเหมือนว่าคำตอบสุดท้ายคือการแก้ให้ Qt draw text โดยใช้ Pure Mono (TlwgMono)
> ได้ใช่ไหมครับ เืมื่อเป็นเช่นนั้น ปัญหาทั้งใน Konsole, Kate/Kwrite ก็จะถูกแก้หมดไปในคราวเดียว
>
> ระหว่างนี้ก็ใช้ Pseudo mono ไปก่อนแก้ขัด?
ผมไม่อยากเจอข้ออ้างว่า "It works for years" แล้วไม่ยอมแก้ให้
อีกน่ะครับ ทำให้ถูกต้องแต่แรกไปเลยจะดีกว่า
ในความเห็นผม ถ้าจะให้มีวิธีแก้ขัด ก็น่าจะเป็นวิธีที่ไม่มีปัญหา
เช่น ใช้การ compose charcell ซึ่งมี spec ของ XLFD รองรับ
(ตาม patch เดิมก่อนหน้านี้) จากนั้น ถ้าเราแก้ Qt ให้ render
monospace ได้แล้ว ก็กลับมาแก้ konsole เพื่อเพิ่มประสิทธิภาพได้
ส่วน kate/kwrite ผมคิดว่ายังใช้ pseudo-mono ต่อไปได้
(เหมือน proportional ทั่วไป) และหลังจากแก้ Qt แล้ว ก็จะกลายเป็น
ใช้ mono ได้เพิ่มขึ้นอีกหนึ่งอย่าง ..สรุปคือไม่ต้องห่วงเรื่อง kate
ในตอนนี้ก็ได้
> ใน Gtk+/GNOME นี่ได้ทั้ง Pure/Pseudomono เลยป่าวครับ
GTK+ ยังไม่ support การจัด charcell ด้วย pure mono
เหมือนกันครับ ตรงนี้เป็น TODO สำหรับ vte ที่ยังไม่มีคนแตะ
Pattara "Ott" Kiatisevi
> 2008/2/2 Pattara Ott Kiatisevi <pattar...@mm.co.th>:
>
>
>> ถ้าังั้นเหมือนว่าคำตอบสุดท้ายคือการแก้ให้ Qt draw text โดยใช้ Pure Mono (TlwgMono)
>> ได้ใช่ไหมครับ เืมื่อเป็นเช่นนั้น ปัญหาทั้งใน Konsole, Kate/Kwrite ก็จะถูกแก้หมดไปในคราวเดียว
>>
>> ระหว่างนี้ก็ใช้ Pseudo mono ไปก่อนแก้ขัด?
>>
>
> ผมไม่อยากเจอข้ออ้างว่า "It works for years" แล้วไม่ยอมแก้ให้
> อีกน่ะครับ ทำให้ถูกต้องแต่แรกไปเลยจะดีกว่า
>
> ในความเห็นผม ถ้าจะให้มีวิธีแก้ขัด ก็น่าจะเป็นวิธีที่ไม่มีปัญหา
> เช่น ใช้การ compose charcell ซึ่งมี spec ของ XLFD รองรับ
> (ตาม patch เดิมก่อนหน้านี้) จากนั้น ถ้าเราแก้ Qt ให้ render
>
OK ครับ ถ้างั้นก็คือ patch เิดิมเหมือนจะดีกว่า
ที่ Konsole เราแยกแยะได้ไหมครับว่าอันนี้ฟอนต์ pure หรือ pseudo mono
กำลังคิดว่าถ้าทำแบบ
if (pure mono) {
// render ด้วยการ compose charcell ซึ่งมี spec ของ XLFD รองรับ
} else {
// pseudo mono/propotional
ส่งให้ QPainter::drawText()
}
ซึ่งถ้าแก้ Qt เสร็จเมื่อใด ก็ลบเหลือแค่ส่งให้ QPainter::drawText() ทั้งหมดจะดีไหม
> monospace ได้แล้ว ก็กลับมาแก้ konsole เพื่อเพิ่มประสิทธิภาพได้
>
ซึ่งการแก้นี่ก็คือการเอา Logic การ compose charcell ที่อยู่ใน patch เดิมก่อนทางหน้านี้
ไปยัดใน Qt หรือเปล่าครับ พี่พอเห็นช่องทางไหมครับ ช่วยชี้ทางสว่างสักนิด
ถาม Qt ไปก็เงียบกริบเลยแฮะ สงสัยยุ่งเรื่องหุ้น Nokia
ซึ่งถ้าแก้แล้วมันจะทำให้ Qt render "Pseudo mono" ไม่ได้?
แล้วมันจะเป็นอะไรหรือเปล่าครับถ้างั้น จะมีกรณีไหนที่ต้องใช้ pseudo mono ไหม
ว่าแล้วก็สงสัยว่าทำไมเราถึงทำ pseudo mono ขึ้นมานะครับ (ถึงแม้มันไม่อยู่ใน spec ใดๆ)
หรือว่าเพื่อแก้ขัดเพราะ toolkit/program อื่นๆ (นอกเหนือจาก Qt) ก็ติดปัญหานี้อยู่เหมือนกัน
หรือถ้าเราใช้ Pseudo Mono ไปเลย จะมีข้อเสียอะไรไหมครับ :-p เหมือนว่าทุกฝ่าย render
ได้สวยงามตอนนี้
ขอบคุณครับ
ภัทระ
Theppitak Karoonboonyanan
> OK ครับ ถ้างั้นก็คือ patch เิดิมเหมือนจะดีกว่า
>
> ที่ Konsole เราแยกแยะได้ไหมครับว่าอันนี้ฟอนต์ pure หรือ pseudo mono
> กำลังคิดว่าถ้าทำแบบ
>
> if (pure mono) {
> // render ด้วยการ compose charcell ซึ่งมี spec ของ XLFD รองรับ
> } else {
> // pseudo mono/propotional
> ส่งให้ QPainter::drawText()
> }
>
> ซึ่งถ้าแก้ Qt เสร็จเมื่อใด ก็ลบเหลือแค่ส่งให้ QPainter::drawText() ทั้งหมดจะดีไหม
ผมว่าเอาอย่างนี้ดีกว่า:
ตัดแนวคิดเรื่อง pseudo-mono ออกจากสารบบคิดเสีย แล้วแยก
ฟอนต์ออกเป็นสองประเภทเท่านั้น คือ monospace กับ proportional
โดยจัดให้ฟอนต์ TlwgTypewriter เป็นฟอนต์ proportional
จากนั้น จะเห็น if-then-else ข้างบนถูกต้องตาม spec ทุกประการ คือ
if (ismono(font)) {
// charcell
} else {
// proportional
}
แล้วตรง ismono() แทนที่จะไปอิง IsFixedPitch() ก็ไปเช็กความกว้าง
ของ combining characer glyph เช่น สระอิ แทน ทำให้ clear cut
ไปเลย ฟอนต์ Typewriter ไม่ต้องเป็นนกมีหูหนูมีปีกอีก
> > monospace ได้แล้ว ก็กลับมาแก้ konsole เพื่อเพิ่มประสิทธิภาพได้
>
> ซึ่งการแก้นี่ก็คือการเอา Logic การ compose charcell ที่อยู่ใน patch เดิมก่อนทางหน้านี้
> ไปยัดใน Qt หรือเปล่าครับ พี่พอเห็นช่องทางไหมครับ ช่วยชี้ทางสว่างสักนิด
ก็คงไม่พ้น language engine นะครับ เพียงแต่ต้องไปล้วงโค้ดส่วน
จัดตำแหน่ง x, y ของ glyph ซึ่งจะเห็นว่าโค้ดเดิมใน Qt4 มีการ
จัดตำแหน่งสระบน-ล่างของไทย ทำให้วรรณยุกต์มีการยักคิ้วขึ้นลงอยู่
ลองไล่โค้ดพวกนั้นอาจเห็นแนวทางมาปรับใช้
> ซึ่งถ้าแก้แล้วมันจะทำให้ Qt render "Pseudo mono" ไม่ได้?
ถ้าแบ่งฟอนต์ด้วย logic ข้างบน ก็จะไม่มี Pseudo mono อีก
มีแต่ monospace กับ proportional โอเคไหม?
> แล้วมันจะเป็นอะไรหรือเปล่าครับถ้างั้น จะมีกรณีไหนที่ต้องใช้ pseudo mono ไหม
> ว่าแล้วก็สงสัยว่าทำไมเราถึงทำ pseudo mono ขึ้นมานะครับ (ถึงแม้มันไม่อยู่ใน spec ใดๆ)
> หรือว่าเพื่อแก้ขัดเพราะ toolkit/program อื่นๆ (นอกเหนือจาก Qt) ก็ติดปัญหานี้อยู่เหมือนกัน
>
> หรือถ้าเราใช้ Pseudo Mono ไปเลย จะมีข้อเสียอะไรไหมครับ :-p เหมือนว่าทุกฝ่าย render
> ได้สวยงามตอนนี้
ความจริง เราไม่เคยมีฟอนต์ monospace ไทยที่เป็นเวกเตอร์
ให้เห็นเป็นตัวอย่างใน commercial platform เลย อย่าง Courier
บนวินโดวส์ก็ไม่มีภาษาไทย (ส่วน fixsys เราไม่ค่อยเอามานับรวม
เพราะมันมีที่ใช้จำกัด เราเอามาใช้ในเวิร์ดไม่ได้ ใน web browser
ก็ไม่ได้ เป็นต้น) การที่เรามี Pseudo Mono ขึ้นมาในลินุกซ์ ก็เหมือน
การสร้างฟอนต์ Proportional ที่มีความกว้างคงที่เท่านั้น (ยกเว้น
combining character) ซึ่งปรากฏว่าใช้ใน web browser ได้
แต่ในอีกด้านหนึ่ง ก็กลับมี solution แบบ charcell ขึ้นมาใน spec
ของ X Window ซึ่งเป็นวิธีการที่ไม่ต้องละเมิด spec เดิม แล้ว app
ประเภท grid screen อย่าง emacs, xterm ก็ใช้วิธีนั้น
ผมคิดว่าถ้าจะทำให้ถูกตาม spec จริง ๆ ก็ต้องทำแบบ charcell
แต่ pseudo-mono ก็ยังมีที่ใช้ใน app ที่ยังไม่ทำ charcell โดยใช้
ในฐานะของฟอนต์ proportional สำหรับโปรแกรม แต่เป็น
"monospace" สำหรับผู้ใช้ (เทียบได้กับ latin hack ใน netscape
สมัยก่อน ที่เป็น latin สำหรับโปรแกรม แต่เป็น tis-620 สำหรับผู้ใช้)
ก็คงต้องมีฟอนต์ pseudo-mono ต่อไป สำหรับ app พวกนั้น
Pattara "Ott" Kiatisevi
> ความจริง เราไม่เคยมีฟอนต์ monospace ไทยที่เป็นเวกเตอร์
> ให้เห็นเป็นตัวอย่างใน commercial platform เลย อย่าง Courier
> บนวินโดวส์ก็ไม่มีภาษาไทย (ส่วน fixsys เราไม่ค่อยเอามานับรวม
> เพราะมันมีที่ใช้จำกัด เราเอามาใช้ในเวิร์ดไม่ได้ ใน web browser
> ก็ไม่ได้ เป็นต้น) การที่เรามี Pseudo Mono ขึ้นมาในลินุกซ์ ก็เหมือน
> การสร้างฟอนต์ Proportional ที่มีความกว้างคงที่เท่านั้น (ยกเว้น
> combining character) ซึ่งปรากฏว่าใช้ใน web browser ได้
>
> แต่ในอีกด้านหนึ่ง ก็กลับมี solution แบบ charcell ขึ้นมาใน spec
> ของ X Window ซึ่งเป็นวิธีการที่ไม่ต้องละเมิด spec เดิม แล้ว app
> ประเภท grid screen อย่าง emacs, xterm ก็ใช้วิธีนั้น
>
> ผมคิดว่าถ้าจะทำให้ถูกตาม spec จริง ๆ ก็ต้องทำแบบ charcell
> แต่ pseudo-mono ก็ยังมีที่ใช้ใน app ที่ยังไม่ทำ charcell โดยใช้
> ในฐานะของฟอนต์ proportional สำหรับโปรแกรม แต่เป็น
> "monospace" สำหรับผู้ใช้ (เทียบได้กับ latin hack ใน netscape
> สมัยก่อน ที่เป็น latin สำหรับโปรแกรม แต่เป็น tis-620 สำหรับผู้ใช้)
>
ในกรณีของเทคนิค latin hack นี่ผมว่ามันร้ายแรงอยู่ กล่าวคือ ทำให้เกิด content
ที่ผิดพลาดอย่างถาวร (จนกว่าจะมีการ convert ไปเป็น encoding ที่ถูกต้อง)
และส่งผลกระทบทำให้ีการ search การ shaping, ตัดคำ (ที่ต้อง detect
ว่าเป็นภาษาไทยก่อนถึงจะทำ) รวมถึง convert ไปเป็น character set อื่นๆ ผิดพลาดหมด.
ทีนี้ในกรณี pseudo-mono นี่มันจะรุนแรงขนาดนั้น หรือมีผลเสียอะไรที่ต้องระวังไหมครับ
บน Mac มีฟอนต์ Monospace ภาษาไทยป่าวว้า..
ส่วนเรื่องอื่นๆ เหมือนจะ get ล่ะครับ ขอบคุณมากครับ
Ott
Theppitak Karoonboonyanan
> > ความจริง เราไม่เคยมีฟอนต์ monospace ไทยที่เป็นเวกเตอร์
> > ให้เห็นเป็นตัวอย่างใน commercial platform เลย อย่าง Courier
> > บนวินโดวส์ก็ไม่มีภาษาไทย (ส่วน fixsys เราไม่ค่อยเอามานับรวม
> > เพราะมันมีที่ใช้จำกัด เราเอามาใช้ในเวิร์ดไม่ได้ ใน web browser
> > ก็ไม่ได้ เป็นต้น) การที่เรามี Pseudo Mono ขึ้นมาในลินุกซ์ ก็เหมือน
> > การสร้างฟอนต์ Proportional ที่มีความกว้างคงที่เท่านั้น (ยกเว้น
> > combining character) ซึ่งปรากฏว่าใช้ใน web browser ได้
> >
> > แต่ในอีกด้านหนึ่ง ก็กลับมี solution แบบ charcell ขึ้นมาใน spec
> > ของ X Window ซึ่งเป็นวิธีการที่ไม่ต้องละเมิด spec เดิม แล้ว app
> > ประเภท grid screen อย่าง emacs, xterm ก็ใช้วิธีนั้น
> >
> > ผมคิดว่าถ้าจะทำให้ถูกตาม spec จริง ๆ ก็ต้องทำแบบ charcell
> > แต่ pseudo-mono ก็ยังมีที่ใช้ใน app ที่ยังไม่ทำ charcell โดยใช้
> > ในฐานะของฟอนต์ proportional สำหรับโปรแกรม แต่เป็น
> > "monospace" สำหรับผู้ใช้ (เทียบได้กับ latin hack ใน netscape
> > สมัยก่อน ที่เป็น latin สำหรับโปรแกรม แต่เป็น tis-620 สำหรับผู้ใช้)
>
> ในกรณีของเทคนิค latin hack นี่ผมว่ามันร้ายแรงอยู่ กล่าวคือ ทำให้เกิด content
> ที่ผิดพลาดอย่างถาวร (จนกว่าจะมีการ convert ไปเป็น encoding ที่ถูกต้อง)
> และส่งผลกระทบทำให้ีการ search การ shaping, ตัดคำ (ที่ต้อง detect
> ว่าเป็นภาษาไทยก่อนถึงจะทำ) รวมถึง convert ไปเป็น character set อื่นๆ ผิดพลาดหมด.
> ทีนี้ในกรณี pseudo-mono นี่มันจะรุนแรงขนาดนั้น หรือมีผลเสียอะไรที่ต้องระวังไหมครับ
ตอนนี้ผมยังมองไม่เห็นผลเสียที่ร้ายแรงนะครับ ที่เปรียบเทียบ ก็เทียบ
เรื่องความ hack เท่านั้น ไม่เกี่ยวกับเรื่องผลกระทบ
แต่คิดว่า ในช่วงเปลี่ยนผ่าน ก็คงมีอาการสะดุดบ้าง เหมือน ๆ กับการ
เปลี่ยนผ่านทั่วไป แต่คงไม่ร้ายแรงเหมือนช่วงปลดระวาง latin hack
หลัง GNOME 2.22 ออก คงได้เริ่มทำเรื่องนี้ที่ฝั่ง GNOME บ้าง
/me ตอนนี้แปล GNOME ก่อน
Theppitak Karoonboonyanan
> ผมว่าเอาอย่างนี้ดีกว่า:
>
> ตัดแนวคิดเรื่อง pseudo-mono ออกจากสารบบคิดเสีย แล้วแยก
> ฟอนต์ออกเป็นสองประเภทเท่านั้น คือ monospace กับ proportional
> โดยจัดให้ฟอนต์ TlwgTypewriter เป็นฟอนต์ proportional
> จากนั้น จะเห็น if-then-else ข้างบนถูกต้องตาม spec ทุกประการ คือ
>
> if (ismono(font)) {
> // charcell
> } else {
> // proportional
> }
>
> แล้วตรง ismono() แทนที่จะไปอิง IsFixedPitch() ก็ไปเช็กความกว้าง
> ของ combining characer glyph เช่น สระอิ แทน ทำให้ clear cut
> ไปเลย ฟอนต์ Typewriter ไม่ต้องเป็นนกมีหูหนูมีปีกอีก
ตรงนี้ คิดว่ามีข้อควรระวังอยู่ คือการทำอย่างนี้ก็หมายความว่า เราจะ
รองรับการใช้ฟอนต์ proportional ทั่วไป (เช่น loma, waree) ใน
konsole ด้วย เพื่อให้ patch สมบูรณ์
ก็จะต้องหาวิธีแก้ปัญหาการแยกสระอำใน proportional ด้วย
วิธีที่น่าจะทำถ้าเป็นไปได้ คือเพิ่มแนวคิดเรื่อง wide cell คือ cell
ที่กินเนื้อที่มากกว่าหนึ่งคอลัมน์ ซึ่งโดยโครงสร้างปัจจุบันของ konsole
ผมไม่แน่ใจว่าจะเป็นไปได้แค่ไหน
wide cell ที่ว่านี้ ต่างจาก double-width ของ CJK เพราะ
double-width นั่น ถ้าใช้ก็จะใช้ทั้ง screen เหมือนกันหมด
แต่เราต้องการใช้ปะปนกับเซลล์ปกติที่กว้างหนึ่งคอลัมน์ด้วย
jakkapun kwanroengjai
> // charcell
> } else {
> // proportional
> }
> แล้วตรง ismono() แทนที่จะไปอิง IsFixedPitch() ก็ไปเช็กความกว้าง
> ของ combining characer glyph เช่น สระอิ แทน
if (painter.fontMetrics().leftBearing(QChar(0xe34)) >= 0)
drawCharSequence(painter,rect,text,style);
else
painter.drawText(rect,text);
Theppitak Karoonboonyanan
> > if (ismono(font)) {
> > // charcell
> > } else {
> > // proportional
> > }
>
> > แล้วตรง ismono() แทนที่จะไปอิง IsFixedPitch() ก็ไปเช็กความกว้าง
> > ของ combining characer glyph เช่น สระอิ แทน
> ในการเช็กความกว้างของ สระอิ ผมได้ลองเช็กด้วย
> painter.fontMetrics().width(สระอิ) ผลปรากฎว่ามันได้ผลเป็น 0 เหมือนกัน (mono
> กับ proportional) (ไม่แน่ใจว่าเช็กถูกค่าหรือเปล่า)
int QFontMetrics::width(QChar ch) const
{
if (QChar::category(ch.unicode()) == QChar::Mark_NonSpacing)
return 0;
// ...
}
เอิ๊ก! -"-
และมีโค้ดแบบนี้ใน method อื่นด้วย.. คงเป็นข้อกำหนดตายตัวของเขา
> แต่พอมาลองเช็กด้วยค่า
> leftBearing ของฟอนต์มันจะสามารถแยกแยะได้โดยถ้าเป็น proportional font
> มันจะมีค่าเป็นลบ และเป็น 1 ถ้าเป็น mono ครับ
> เราจะสามารถใช้ค่านี้ในการตรวจสอบได้หรือเปล่าครับ
> if (painter.fontMetrics().leftBearing(QChar(0xe34)) >= 0)
>
> drawCharSequence(painter,rect,text,style);
> else
> painter.drawText(rect,text);
ก็คงพอได้... (จะมีภาษาไหนมี combining character ล้ำไปทางขวา
แทนไปทางซ้ายไหมหว่า)
ผมเพิ่งได้อีกไอเดียหนึ่ง ซึ่งต้องแก้ที่ฟอนต์ โดยอาศัยความสามารถของ
OpenType คือใส่ anchor เชื่อมอักขระฐานกับสระบน-ล่างเสีย
จากนั้น ฟอนต์ monospace ก็จะ compose charcell โดยอัตโนมัติ
กล่าวคือ ถ้าได้ฟอนต์ที่ว่ามา ก็ใช้แค่ painter.drawText() อย่างเดียวได้
แบบนี้ ก็จะไม่มีการแบ่งแยก mono/proportional ในโค้ดเลย
และการแก้ฟอนต์ก็ไม่ได้กระทบความเป็น monospace ตาม spec ด้วย
เดี๋ยวผมลองแก้ฟอนต์แล้วส่งมาให้ทดลองทีหลัง
แต่ทั้งหมดนั้นก็แก้ปัญหากรณีทั่วไปได้ แต่ยังไม่ได้ตอบคำถามเรื่องการ
จัดการสระอำกับการ render ฟอนต์ proportional ทั่วไปเลยน่ะ
ถ้าจะทำไม่รู้ไม่ชี้ไปก่อน แล้วให้ผู้ใช้ใช้แต่ mono ก็ถือว่ายังทำเนียนได้
เพราะเราไม่ได้แสดงเจตนาชัดแจ้งว่าจะ support เหมือนการใส่
if block ข้างบน การ patch เพิ่มภายหลังก็จะถือเป็น "enhancement"
ไม่ใช่ว่าเราวางบั๊กไว้ (ฟู่ เหนื่อยจริงเนาะ ต้องคิดเรื่องการเมืองกับ
upstream ไปด้วย)
แต่ถ้าจะทำเพิ่มเลย ก็ต้องหาทางเพิ่มฟีเจอร์ wide cell ที่พูดถึงน่ะ
Theppitak Karoonboonyanan
> ผมเพิ่งได้อีกไอเดียหนึ่ง ซึ่งต้องแก้ที่ฟอนต์ โดยอาศัยความสามารถของ
> OpenType คือใส่ anchor เชื่อมอักขระฐานกับสระบน-ล่างเสีย
> จากนั้น ฟอนต์ monospace ก็จะ compose charcell โดยอัตโนมัติ
> กล่าวคือ ถ้าได้ฟอนต์ที่ว่ามา ก็ใช้แค่ painter.drawText() อย่างเดียวได้
>
> แบบนี้ ก็จะไม่มีการแบ่งแยก mono/proportional ในโค้ดเลย
> และการแก้ฟอนต์ก็ไม่ได้กระทบความเป็น monospace ตาม spec ด้วย
>
> เดี๋ยวผมลองแก้ฟอนต์แล้วส่งมาให้ทดลองทีหลัง
ได้ละ ฟอนต์ยังไม่เรียบร้อยดี แต่ผมทดลองกับ pango แล้ว render ได้
แต่ไม่ค่อยแน่ใจว่าจะได้ผลกับ app อื่นด้วยไหม ฝากลองกับ kate ก่อน
แล้วค่อยลองกับ konsole (โดยมีแต่ painter.drawText() อย่างเดียว)
นะครับ
jakkapun kwanroengjai
> แต่ไม่ค่อยแน่ใจว่าจะได้ผลกับ app อื่นด้วยไหม ฝากลองกับ kate ก่อน
> แล้วค่อยลองกับ konsole (โดยมีแต่ painter.drawText() อย่างเดียว)
> นะครับ
ทดลองกับ konsole ดูแล้วเรียบร้อยดี ครับ
:)
Pattara "Ott" Kiatisevi
ส่ง updated patch ไปล่ะ http://bugs.kde.org/show_bug.cgi?id=156071
default Thai monospace font ใน Debian/Ubuntu นีี่เราตกลงใช้อะไรเหรอครับ ผมดูใน
/etc/fonts/conf.d/65-ttf-thai-tlwg.conf ของผมเป็น TlwgTypist แฮะ ไม่ใช่ทั้ง
TlwgMono และ TlwgWriter
แต่ว่าสีฟอนต์เหมือนเข้มดี
Ott
Theppitak Karoonboonyanan
> default Thai monospace font ใน Debian/Ubuntu นีี่เราตกลงใช้อะไรเหรอครับ ผมดูใน
> /etc/fonts/conf.d/65-ttf-thai-tlwg.conf ของผมเป็น TlwgTypist แฮะ ไม่ใช่ทั้ง
> TlwgMono และ TlwgWriter
ผมอาจจะลืมใส่ นานแล้วจำไม่ได้เหมือนกัน :P
เดี๋ยวขั้นต่อไปคือทำ TlwgTypo (มีชื่ออื่นดี ๆ มะ) ใน
thaifonts-scalable รุ่นหน้า
/me กี่อย่างแล้วหว่า TODO ฉัน.. รอหน่อยนะคร้าบ