Android Canvas繪制文字橫縱向?qū)R
1. 橫向?qū)R(Align屬性)
Align屬性決定了使用該畫筆時,相較于繪制點的水平對稱方式,分別是LEFT、CENTER、RIGHT,對應的情況:
如最上方的文字及其框線所示,文字具有三個備選的初始繪制基點,Align屬性將會指定這三個綠色的哪一個基點最終和繪制目標基點進行重合對齊。
紅色的點就是我們在drawText()中填入的xy坐標參數(shù),我們暫且將其稱為目標基點
(x,y)被確定之后,文字繪制的基線baseline
就可以確定了。而Align屬性,正是決定了使用文字的左、中、右,具體哪一個點作為參照點和繪制的基點進行重合,例如我們設(shè)置align = Align.LEFT,那么就是文字的左邊一個初始基點與目標基點(x,y)進行對齊,繪制的結(jié)果就是所有文字都在基點的右邊。
注意:以上的圖片只是理想情況,實際繪制時,如果不作處理,那么你會發(fā)現(xiàn)在LEFT、RIGHT模式中,框線和目標基點(x,y)之間還有一小段距離。
2. TextBound
該屬性本質(zhì)上是一個矩形(Rect),如果我們將該矩形繪制在屏幕上,那么它的位置非常奇怪,它會出現(xiàn)在左上角的位置上,如下圖左上角黑色框線:
實際上,我們不應該不經(jīng)過處理直接將這個矩形繪制出來,因為它所對應的實際的量僅僅代表的是我們當前繪制字符的Bound,即邊界,我們利用bound.right - bound.left
就可以得到使用當前Paint繪制當前字符最終得到的寬度,同理可以得到繪制字符的高度。而它實際的數(shù)值標識的意義應該是在Align.LEFT模式下,左右、上下框線距離繪制基點的偏移量。例如如下視圖,對應的數(shù)據(jù)分別是:
如果我們使用如下代碼將Text繪制在Canvas的中心,同時將Bounds也按照一定的偏移繪制出來,讓它緊緊地貼著文字:
// 繪制內(nèi)部文字,centerPoint是一個數(shù)組,存儲了視圖中心點的坐標 canvas?.drawText(mText, centerPoint[0], centerPoint[1], mTextPaint.apply { textAlign = Paint.Align.LEFT }) // 繪制框線 canvas?.drawRect( ?centerPoint[0] + mTextBound.left, ?mTextBound.top.toFloat() + centerPoint[1], ?mTextBound.right.toFloat() - mTextBound.left.toFloat() + centerPoint[0], ?mTextBound.bottom.toFloat() + centerPoint[1], ?mTextBoardPaint.apply { ? ?strokeWidth = 8f } )
其中黑色的點是整個視圖的中心,細心的小伙伴可能發(fā)現(xiàn)了,黑點并不是文字的最左下方,而是偏靠上了一點點,我們把這條線延展出來,那么就可以得到該文字的繪制基線:Baseline
。
為什么要設(shè)置這樣一個Baseline
呢?
其實不難發(fā)現(xiàn),基線以上,幾乎包括了95%的文字內(nèi)容,而基線以下,只有p、q、Q的尾部。主要部分完全都被包含在了基線之上?;€其實是西文字體設(shè)計與排版的概念,源自西文字母的主體底部對齊的位置,如果直接按照bounds的底部進行繪制文字,顯然這些p、q、Q的尾部是無法處理的。但是如果只有字符「abcd」的情況下,你會發(fā)現(xiàn)文字的邊框完全貼著a的底部,因為在這種特殊的情況下,基線和bound的底部完全重合了。
但基線對于中文來說并沒有多大的意義,但是它卻一定程度上影響到了我們繪制時所期望的定位方式,我們肯定是希望文字一定是嚴格按照文字的左下角、中心下角、右下角來繪制的,我們不希望文字底部和這個基線之間還有一小段距離。這個問題在一些需要做到豎直居中的場景中尤為尖銳,譬如我們希望在圓形中嵌入一個字符,標識某種信息,如果我們直接在視圖中心drawText,繪制出的文字卻不在視圖的中心:
原因很簡單,文字的縱向中心和圖像的縱向中心并不重合。
3. 縱向?qū)R與繪制線
leading
: 上一行文字的descent到當前行文字的ascent稱為行距
Top
:最高字符到Baseline
的值,以Baseline
為基準,向下為正(通常Top為負值)Asecnt
:Baseline
之上至字符最高處的距離,以Baseline
為基準,向下為正(通常為負值)Baseline
:文字繪制的基準,該屬性并不在fontMetrics中顯示地給出,通常設(shè)置Paint的Align的時候,我們所設(shè)置的點的水平延長線就是基線Descent
:Baseline
之下至字符最低處的距離,以Baseline
為基準,向下為正(通常為正值)Bottom
:最下字符到Baseline
的值,以Baseline
為基準,通常為正值
在Android中,我們可以使用:Paint.getFontMetrics()獲取以上的絕大部分數(shù)值(除了Baseline)。
其中,Descent和Ascent中容納了整個文字的內(nèi)容,除去p、q的尾部,其余的主要內(nèi)容則位于基線和Ascent之間,在一些特殊的文字系統(tǒng)中,可能含有「Ö」這一類的字符:
這樣就會將文字的bound撐開到Ascent的位置,此時的bound中線和Ascent/Descent幾乎完全重合了,對于上面提到的居中的問題,我們也不難得到一個解決方案,將文字繪制的起點向下偏移一小段距離即可完成居中,而這偏移的一小段距離應該是文字bound居中線y坐標和繪制起點y坐標之間的差值,如下圖X標注:
代碼如下:
?canvas?.drawText(mText, centerPoint[0], centerPoint[1] + mTextBound.bottom, mTextPaint.apply { ? ?textAlign = Paint.Align.CENTER })
只需要將繪制基點向下移動:基線到文字底部的距離,即bound.bottom即可:
4. 總結(jié)
繪制線(Metrics)是由Paint和字體共同決定的,當一個Paint和字體確定了,那么上述的繪制線就已經(jīng)確定了,并不會因為文字內(nèi)容的變化而被修改;而textBound則是文字繪制的邊界,我們使用Paint.getTextBounds()可以去測量特定內(nèi)容的邊界值,其值根據(jù)文本的內(nèi)容的不同而有所不同。在繪制內(nèi)容中,如果含有當前字符集中的最“高”的字符時,bound的bottom、top與繪制線的Ascent、Descent之間分別會重合。
因此,Ascent和Descent之間是當前字符集中最高文字的頂和底,它不一定出現(xiàn)在你的內(nèi)容當中;而bounds的top和bottom對應的中心,則是你實際繪制的內(nèi)容的縱向中心。
到此這篇關(guān)于Android Canvas繪制文字橫縱向?qū)R的文章就介紹到這了,更多相關(guān)Android Canvas繪制 內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家!
相關(guān)文章
android 仿微信demo——注冊功能實現(xiàn)(移動端)
本篇文章主要介紹了微信小程序-閱讀小程序?qū)嵗╠emo),小編覺得挺不錯的,現(xiàn)在分享給大家,也給大家做個參考。一起跟隨小編過來看看吧,希望能給你們提供幫助2021-06-06Android Studio 3.0 原生支持kotlin 例子詳解
這篇文章主要介紹了 Android Studio 3.0 原生支持kotlin 例子詳解,非常具有實用價值,需要的朋友可以參考下2017-05-05Android如何讓APP無法在指定的系統(tǒng)版本上運行(實現(xiàn)方法)
這篇文章主要介紹了Android如何讓APP無法在指定的系統(tǒng)版本上運行(實現(xiàn)方法),本文給大家介紹的非常詳細,對大家的學習或工作具有一定的參考借鑒價值,需要的朋友可以參考下2021-02-02Flutter 用自定義轉(zhuǎn)場動畫實現(xiàn)頁面切換
本篇介紹了 fluro 導航到其他頁面的自定義轉(zhuǎn)場動畫實現(xiàn),F(xiàn)lutter本身提供了不少預定義的轉(zhuǎn)場動畫,可以通過 transitionBuilder 參數(shù)設(shè)計多種多樣的轉(zhuǎn)場動畫,也可以通過自定義的 AnimatedWidget實現(xiàn)個性化的轉(zhuǎn)場動畫效果。2021-06-06