小松鼠嚇了一跳,有了魔法眼鏡後,這世界看起來完全不一樣了

2012年10月27日 星期六

Macbook Air 11" 2012 使用心得

查看今年在 coscup 的  irc log,發現我的旗艦筆電慘遭嘲笑:
11:38 < *******> [R1] 講者故意帶了很慢的電腦來展示
憤而決定更換新機。
開玩笑的,真正的原因是我常常上課或演講帶著筆電跑來跑去,雖然我連拿著磚塊般的 Xoom 都舉重若輕, 但因為加上電線、書本一堆的,常常還是覺得有點狼狽,所以就打算使用輕薄一點的機型。速度倒不是主要考慮的因素。雖然可能的選項還挺多的,但總之,最後選到了 Macbook Air 11" 2012 128G SSD 這款。
記得我的上一台蘋果電腦,是.......沒有。小學時家裡放了一台舅舅借的 Apple II 相容機。不過那時我還不會寫程式。後來學寫程式也是從 Apple II 的 basic 開始,但那時自己沒有機器,都是借用學校的。後來為了想拿麥金塔當獎品,參加蘋果的電腦繪圖比賽,最後拿到兒童組亞軍,只拿到一本「蘋果戰爭」的書。後來用 executor, pearpc, virtualbox 等模擬器跑過一些蘋果的作業系統,但沒有真的在用。所以我對 osx 完全不熟。
所以,以新手的角度,簡單的描述一下心得讓有類似需求的人參考。


  1. 效能方面,配備有 1.7ghz 雙核心 core i5,GPU 是內建的 HD4000。記憶體我升級到 8G, cpu 雖然也有升級的選項, 但我認為 core i5 已經足夠。實際上使用的心得也是如此。效能方面大致上符合需求。
  2. 重量 1.08 公斤。雖然比 Xoom 還重,但也許是外型扁平(空氣浮力?),也許是心理因素,拿起來並不感覺特別重。總之,比之前的筆電好攜帶多了。機器可以放入我為了 Kindle 買的套子。事實上,我常常將 Kindle 加上 MBA一起放入平板套中攜帶,有時還將手機一起塞進去。
  3. 續航力是比較不滿意的地方,不過這是購買前已經了解到的事情。待機之類的耗電不多,開機很快,所以不用的時候,關機即可。但問題是持續使用的情形下,使用時間比平板要短一些。兩三個小時的使用不成問題,但時間久一點(比方一整天),跑的東西多一點,就會有點擔心電力的問題。雖然不見得真的會沒電,但因為這個擔心,可能會讓你考慮要多帶個充電器。
  4. 螢幕雖小,但解析度還可以,所以其實使用上問題不大。我有實際試過在搭乘客運時 coding,的確可以工作。不過有老花眼之後,可能就不行了。
  5. 找不到怎麼改字體大小,除了改解析度的方式外。
  6. OS X 的使用一開始並不順手,但磨合期不會太長。最主要是要熟悉多點觸控手勢。由於螢幕小,大多數是使用單視窗邏輯去操作,所以固定在最上層選單使用起來不像 ubuntu 的 unity 那樣彆扭。
  7. 中文輸入法的設定/安裝經驗不好。由於我使用許氏鍵盤注音,所以得額外安裝支援許氏鍵盤的輸入法。一開始使用 Openvanilla,但後來發現酷音要另外裝。上網找了一些安裝方式都裝不起來,我就放棄了。最後使用 Yahoo 的輸入法。但是 Yahoo 輸入法要選擇許氏鍵盤居然還要靠秘技才行?
  8. 軟體包含許多實用的軟體,比方說 quick time 能將螢幕畫面錄下來。想放上 youtube,可能會想自己配樂。雖然 youtube 有提供一些音樂讓你配音,但其中一些似乎會強迫在你影片中放廣告。所以,可以自己用 garageband 放一些簡單的配樂進去。Facetime 的畫質和效果就我個人的經驗來說,是同類型最佳。
  9. xcode 我用了一下,還沒有上手。
  10. 由於 128G 的 SSD 不很大,根據網路上的資訊,我選擇用相對較省空間的 brew 來管理開源向的套件。當然也裝上了 python。雖說 osx 的底層是 bsd,但很多東西的支援度還是有差。比方上圖是最近練習寫的小遊戲,用的是 pyglet。pyglet 在 mountain lion 上跑不起來。當然最後我還是跑起來了,因為用了 1.2 alpha,而且還修改了裡面的 bug 才能跑(搜尋網路找到的)。但即使如此,跑起來還是有小問題。
  11. 另外一個例子是 pcsx。下載官網事先編譯好的可執行套件,會發現無法使用硬體加速 plugin。原本我打算自己寫,不過下載好 source 後發現其實自己 compile 之後就有硬體加速的 plugin 了。總之,就是開源向的東西支援完整度沒有那麼好。不過,一部分的原因也是因為 mountain lion 本身的向下相容性問題。

以不到四萬元的機器來說,我認為是滿意的。目前大致上取代了 xoom 和原本筆電的功能。

2012年10月9日 星期二

用 Python 將漫畫轉 PDF 給 Kindle DX 用



Kindle DX 的 824x1200 解析度拿來看黑白漫畫還算合適。可以直接轉圖檔來看,但是 Kindle DX 的看圖軟體並不是很穩定。也可以用一些免費的 pdf 工具來把圖檔組合轉成 pdf 檔,但並不是很能隨心所欲的控制解析度。
所以這裡利用 python 的 reportlab 來做。
底下是先利用 PIL 先將圖檔切兩半,然後增加對比,壓縮成 JPEG,最後再利用reportlab 將圖檔放入 pdf 中即可。
from glob import iglob
from sys import argv
from io import BytesIO
from PIL import Image, ImageOps
from reportlab.pdfgen import canvas
from reportlab.lib.utils import ImageReader
dxsize=(776,1150)
pathname=argv[1]
c = canvas.Canvas( pathname+".pdf",pagesize=dxsize)
for fn in sorted(iglob(pathname+"/*.jpg")):
    img=Image.open(fn).convert("L")    
    w,h=img.size    
    im_split = map(img.crop, [(w/2,20, w, h), (0,20, w/2, h)])    
    im = [img.crop((0,20,w,h))] if w < h else im_split    
    for imgx in im:
        imgx=imgx.resize(dxsize, Image.ANTIALIAS)
        imgx=ImageOps.autocontrast(imgx, cutoff=10)
        tmpio=BytesIO()
        imgx.save(tmpio, "JPEG", quality=70)
        tmpio.seek(0)        
        c.drawImage(ImageReader(tmpio), 0, 0)
        c.showPage()
c.save()

裡面的 dxsize 是根據 mobileread 的網友實驗出來,kindle dx 中 pdf 可用的最大圖檔解析度。雖然 pagesize 的單位是 point 而不是 pixel,但看起來似乎這樣是對的設定。
由於抓來的圖檔對比太弱,利用 autocontrast 來加強對比。
im_split 那行是將圖切回左右兩頁,上面的 20px 是去掉漫畫網站的 mark。
ImageReader 其實吃 PIL 的 Image,但為了能夠控制 JPEG 的壓縮率,所以利用 BytesIO 來當暫存檔。由於某些 PIL bug 的緣故,雖然理論上 Image.save 應該要能吃 BytesIO,但是上面的程式碼會出錯,因為 PIL 沒有處理某些 BytesIO 丟出的 exception,所以我手動修改 PIL 的程式碼讓,save 能吃 BytesIO,也許改成 StringIO 也可以避開這個問題。
原先還想說是否要 dithering,不過至少漫畫看起來還可以接受。

倒也不是非得一定要用 python 寫,我同時也有抓 pdf fill 這樣的現成工具。只是剛好網路有點慢,還沒有抓完 pdf fill,已經先裝好 PIL、 reportlab,然後寫出上面那個程式的雛型了(不過原來沒有用 BytesIO 而且是用 reportlab 比較高階的寫法)。