FreeBSD での Office 環境を語れ! その2
■ このスレッドは過去ログ倉庫に格納されています
>>763
はあ？７はまだ市場に出回ってないだろ。何情報通ぶってんのこのくそが？
ひょっとしてRCのこと？おれも使ってるよ。
ユニクソでは絶対実現できない素晴らしいクオリティだよ。
初めて７にオフィス２００７入れて立ち上げたときおれマジ泣いたもん。
unixつかいはわざわざWindows・・・って、普通逆だろ。
何事実捏造してんだよこの昭和の化石が。
macとかiworksとか何の暗号だよそれwww
ひょっとしてカビリンゴのマッコとセットで売られてるMS Officeのばったもんか？
ホントユニクソユーザーって勘違い時代遅れのバカが多いよね。
本気でWindowsより安定してスケーラビリティあると思い込んでるからね。
うちの会社はユニクソ全部切り捨ててWindows Serverにした途端運用コストも下がって
安定度も増して、社員のモチベーションも上がってこの不況の中業績うはうはだよ
>>764
> まあ、作業スピードじゃオフィスにまったくかなわないですけど。
はぁ?
数式多用するような文書を書くなら latex 使った方が office より早いだろ
>>765
もうすぐ出る＝まだ出てない
何が問題なの？ office環境ってそもそも何。
適当なjavascriptでブラウザ上でも類似のことはできるご時世
MsofficeもそうだけどOOoとかlatexとか化石な気がする。
テキストで素早くタグがかける人ならむしろテキストエディタがあれば充分だろ。
テンプレート文書ならばPHPかなんかローカルかローカルサーバで動かした方が
excelなんかよりよっぽど使いやすい。
Msofficeがいいなら何もOOo使わないで
UNIX上でMSOffice使えばいいだけのこと
その上で好みのアプリ名を語ればいいさ 770の書き込み見てもしやとおもって調べたら、MsOfficeはSuSEとかで起動できるらしいね。今まで知らなかった。
やっぱりmonoとかを使うのかな？
でもやっぱり、いくら互換と言っても本家に比べていろいろ細かい不具合とかありそうな感じ・・・ >>762
はい、そんなに貧乏なんです。Windows7は無料ですか？
Windows7はCPUが450MHzで問題なく動きますか？
インストールメディアはCDかフロッピーですか？
であれば使ってみたいと思います。
>>771
http://www.winehq.org/
確か10年以上まえからMSOffice動くようになってたと思う。
日本語の扱いはまだ怪しいところがあるけれど。
OOoLatex Linux用 って freebsd だと何でクラッシュするの？
スクリプトに OS も何もないはずだが。。。 >>775
ktrace してみればどこで落ちてるかはわかると思うけど。
ググって ktrace を初めてやってみた。
ktrace.out できたんだが、どうすれば良い？ >>777
kdump して MAMI あたりを見てどこで落ちてるか見当をつける。 kdump してみましたが分からなかった。↓が ktrace.out です。何かわかりますか？
http://www1.axfc.net/uploader/Sc/so/39476 ねえLyxってどう？
使っている人見たことないけど… ja-openoffice.org-3.2.20090926
これ重いしすぐクラッシュするけど、うちのところだけ？ devel使うんなら、自分で問題探して報告する勢いじゃないと openoffice入れようとしたけどmakeで容量が足らずにエラー吐いて終了
何十ギガ必要なんだよマジで FreeBSDでHDDはフリーで20Gぐらい必要だったはずだ。メモリは２Gだったかな。
オレは仮想環境でコンパイルしてるけどメモリは少なくてもなんとかなるみたい。 >>784
ありがとう
あと+10GBも必要なのか……まだ導入は厳しいな OpenOffice.orgからLibreOfficeに移行したほうがいいのかな？
3.4のjaだとportupgradeできない。LibreOfficeは日本語大丈夫なのかな？ OOoやLOはバイナリでいれりゃいいやん
セッセとmakeしたところで使用感変わるわけでもなし まぁ、ヘルプから「………について」で自分の名前がでるからな。 >>787
portupgrade -aで用事してる間に他のと一緒に全部済むのはありがたい。
私にとって問題はportsかpkgかじゃなく日本語と今後の存続です。
portmaster -a ならR***もいらなくなるよｗ とっくの昔にOpen OfficeがLibre Officeに変わってますぞ。 FreeBSDとLinux比較した時
クライアンス運用ならFreeBSDのが劣っている点はなんですか？ 「クライアンス」が何か解らんのでググッてみたら、悪徳商法の会社かよ
それがどう関係するのかこれまた解らんが、FreeBSDが劣っていると決めつけているわけね… >>794
"クライアンス運用" でぐぐってみ。
コピペだよそれ。 LibreOffice 3 の FreeBSD package どこかにないかしら? 開発のアクティビティはLibreOfficeの方が上でも、質はOPEN OFFICEのが上ですよね? 教えてください。起動しましたFreeBSD9.3をCD-Rに
OpenOfficeをつかうDVDドライブでとまります。
よろしくお願いしました 書きましたの同じ。起動しましたはとまります。
よろしくお願いしました FREEＢＳＤはオフアイスの焼いたUSBにISOファイルでコンピュータに搭載しましたが
起動しません。
インストールはどこですか？
すみませんお願いします。 FreeBSDなんか選んじゃう、選ばれた一部のエリートが
Officeを使うとは思えない wimeとは、Wine環境下にインストールされたWindows用日本語IMEを
Cannaサーバに見せかけて、Unix界に蓄積されたCanna系ソフトウェアを
そのままで使えるようにする、というものです。
「FreeBSDでwimeを使ったよ、こういう手順だよ」という報告は、
ググりようが足りないのか見かけません。
（FreeBSDのメーリングリストは参加していません）
Linux界でも2008年頃の記事が有名で新しい記事は見かけません。
FreeBSD界では、かけまわる子犬（たかちゃん）氏が、ややふれている
程度です。（http://running-dog.net/2009/09/post_161.html）
「記事の続きを書いてください」「ports化はどうなりましたか」との
コメント書き込みはできず（FreeBSD雑誌で記事を書いていたと記憶し、
おそれ多いです）、もんもんとしていました。
現在では、wimeを利用するには、公式サイトで記述があるように、
パッチをあてたWineを用意しないといけない状況です。
私のようにFreeBSDを使わせてもらっている「だけ」のユーザにとって
Wineの自前でのビルドは、かなりハードルが高い状況です。 ですが、FreeBSDでwimeをインストールし、使えたので報告です。
やってみようと考えた理由は、「よく考えれば、portsはソースから
ビルドしている。portsの枠組みのなかで、Wineにwimeのパッチを
あてられないものか」と思いつき、ググったところ、FreeBSD HandBook
（もちろん日本語版）に、portsでのパッチの説明があったからです。
ブログやツイッタはしておらず、2chのFreeBSD初心者質問スレには
お世話になったと感じているので、報告は2chで、と思いました。
昔、書いたことがある「FreeBSDでのOffice 環境を語れ!」スレを
初出にしたいと思いました。
自分の著作権的には、出典を明記（一次出典にたどり着ける）する
なら転載引用可です。 慣れない方でも理解できるように、やや冗長に書いています。
（環境）FreeBSD11.0-RELEASE-p10 (i386)
ports：wine-devel-2.7 ※develである必要はありませんが
pkg：ja-canna-lib-3.7p3 ※wimeビルドのため
pkg：ja-canna-server-3.7p3 ※canna-libが依存
pkg：gmake-4.2.1 ※wimeビルドのため
wime-3.5.2.tar.bz2 ※当然必要
■ portsのWineにwimeのimm-magicパッチをあてる
1. % /usr/bin/tar xvzf wime-3.5.2.tar.bz2（ユーザー権限でよい）
2. ほどいた wime-3.5.2/patch/imm-magic-1.7.3 の記述内容を変更。
最初の２行の両行とも、以下のようにバージョン名を削除。
wine-1.7.3/dlls/imm32/imm.c → dlls/imm32/imm.c
※すべきかどうかわかりませんが、patchの文法を知らないので。
3. imm-magic-1.7.3 → patch-imm-magic-173 などとファイル名を
リネームし、
/usr/ports/emulators/wine-devel/files/patch-imm-magic-173
などと置く。
※リネームはしなくてもよいと思いましたが、すでに置かれている
他のパッチの命名方法にならいました。パッチをあてる順番の
正解はわかりませんが、imm.cを見ると、C言語はわかりませんが
パッチ通りに変更されているように思えました。
4. ports/emulators/wine-devel 下で、「# make ; make install」
私はmakeオプションは特に変えませんでした。
make install一発でも、portinstallとでも、お好きにどうぞ。 ■ wimeのmake ※要 gmake
1. wime-3.5.2/conf.mk を対象にmake時の変数を変更。
wimeのPREFIXと、WineのWINEDIRは、FreeBSDでは、/usr/local。
・FreeBSDでCLANGなので「USE_CLANG?=1」へ変更。
・FreeBSDなので「FREEBSD?=1」へ変更。
2. なぜか「/usr/local/lib32がなんとか」（i386にはない）と
メッセージが出て「/usr/lib/ld:cannot find -lX11」と
エラーが出てgmakeが止まるので、wime-3.5.2/io/Makefileの
日本語コメント「#amd64でi386-wineを動かしているとき」以下の
二つ続いているendifまでの文脈のかたまりをコメント化。
※修正する能力がないのでコメント化しました。
3. wime3.5.2下で、ユーザー権限でよいので「% gmake」。
4. root様で「# gmake install」し、root様で「# ldconfig」。
■ ATOK17（一太郎2004添付）をWineへインストール
・インストール媒体直下のAUTOPLAY.EXEでも、ATOKディレクトリ下の
SETUP.EXEでも普通にインストールでき、他年度版のように
インストールにコツが必要ではありませんでした。
・wime3.5.2のReadme.atokでの指摘通り、Wineのregedit.exeで
値を e0020411 → e0010411 へ変更する。
※一発登録できるレジストリファイルを作る能力はありません。 □ 注意（私はハマりました）
Unixプログラムから、Wine上のWindowsプログラムに対して
ファイルドラッグが効くこともあり、また、Windows用のウィルス
などを考慮して、Wineには最低限のドライブしか割り当てていない
（Unixシステムのファイルシステムを見せないようにしている）方が
いるかもしれません。
ですが、winecfgの設定で、Z:ドライブなどにファイルシステムの
ルートを割り当てるなどして、Wineから/usr/local以下が見える
ようにしておかないと、wime起動時に
「wine:cannot find 'wime.exe.so'」と言われて起動できないので
注意してください。 □ 動作確認
使い方はwimeのReadmeをご覧ください。
「USE_XIM?=0」へ変更したので他の環境はわかりませんが、
emacs25.1.1 + yc.el(yc-5.2.1)や、scim-cannaで動いています。
Cannaと同程度に軽いです。
が、にわかには自分の能力（今回のインストール）が
信じられません。
もしかして起動を切り忘れたCannaが動いているんじゃ……、
ATOKでしか変換できない文章はないものか……。
「そうだ！2004年当時のジャストシステムの社長名を変換！」
（あとから思うとわれながらバカです）と、ググったところ、
ジャストシステムのサイトに二重敬語の校正指摘の例文があったので
これを変換してみました。
「お読みになられる《二重敬語「→お読みになる」》」で確定。
キター！
※校正説明がくっついたまま確定するのが嫌ならば、wimeの
Readme.atokにある通り、wimectrlでATOKのプロパティを出して
校正支援機能を切ればよい。私は「これぞATOK」なので切らない
けれど。
いろいろと変換してみましたが、やはり歴史の蓄積がある
商用かな漢字変換はすごいものです。 OS添付でない別売りの商用かな漢字変換はPC9801のDOSのWX2+以来です。
つうか、ATOK自体、使ったのは初めてです。
なんだか文豪になれそうです。ウヒョヒョ。
.cannaを読んでくれる環境なので英語配列のHappyHackingKeyboard用に
自分用に書いたCannaのかな入力のJibun_Kana.kpdefを使い続けられて
大満足です。ウハウハ。
wime開発者のthomas氏には大大大感謝です。WineにもFreeBSDにも、
……かかわるみなさんに大感謝です。
特にthomas氏にはFreeBSDを配慮いただき、古場正行氏
（『BSDを256倍使うための本』によると、emiclockのX移植時、
他のOSの事も考えたという）を連想し、感動しました。
ジャストシステムにも感謝……、は半分に減らそう。
完全に「お前の環境」ですが、ATOKは、半角英数記号（1byte文字）や
特定の全角記号（2byte文字）を読みにして単語登録できない
（公式のFAQ）から。
かけまわる子犬（たかちゃん）氏の前出の記事によるとports化は
「手ごわい」とありますが、Wineのportsでmakeオプションに
「Use wime」みたいなものをつけてもらえたら、wimeのports化は
すぐなんじゃないでしょうか。たしか、emacs23の時に「WITH_CANNA」
オプションが採用されましたよね。 2004年とかだったら、ATOK X3 for Linuxを使うのとどっちが楽なんだろ あくまで手持ちがATOK17(2004)だっただけで。
ATOK X3 for Linux か……。
動いている方と動いていない方と。
http://d.hatena.ne.jp/ytetsuwo/20080513
http://d.hatena.ne.jp/tueda_wolf/20080329/p1
wimeがある今となっては、Wine+wimeの方が
継続使用しやすいと思います。 誰でも簡単にパソコン1台で稼げる方法など
参考までに、
⇒ 『宮本のゴウリエセレレ』 というブログで見ることができるらしいです。
グーグル検索⇒『宮本のゴウリエセレレ』
4VUMWMKFUR LibreOfficeのWriterで差し込み印刷をやってみたけど、複数ページ(全ページを含む)印刷ができない
CUPSのジョブを見るとfailしてる
1ページづつ印刷すれば問題ないけど、これじゃ差し込み印刷の恩恵が… そもそも差し込み印刷以前に、用紙がUS レターに固定されてるから、LibreOfficeは日本では使えないでしょ。 デフォルトではあるけど、固定されてはいないよ
実際、A4やハガキで印刷してるし
というかLibreOfficeの話ではないと思うけど へー直ったのか、と思って久々に見たけど変ってないな。
Writerは Format -> Page でA4 に出来るけど、
Impress では何をやっても、プリント時の用紙はLetterで固定。変更出来ない。
日本では無用なソフトですな。Windows用やLinux用がどうなのか知らないけど。 Linuxの6.0.3.2のImpress起動してみたら用紙はA4がデフォルトになってた。 >>818
Inpressか
プロパティでページの書式はA4に変更出来るけど、
印刷しようとするとレターしかないね >>821
＞>>818
＞Inpressか
＞プロパティでページの書式はA4に変更出来るけど、
＞印刷しようとするとレターしかないね
そうそう。handout タブでA4を選んでいても印刷時には全く反映されずレター固定。
4.x までは印刷時に選べたんだけどね。5.x 以降で選べなくなった。で、最新の6.2でもそのままこのバグは残ってる。
まぁ、開発陣はレター圏で使えればオッケーだろうし、ずっとこのままだろうな。 そう言えばWriterも
書式 → ページ → ページタブ で用紙サイズを選ぶのはもちろん、
かつ用紙トレイを[プリンターの設定から]以外の「トレイ」等にする必要がある
それでも印刷しようとするとレターがデフォルトなので、
プロパティ → デバイスタブ で用紙種類を選び、現在の値に「はがき」を選んでやっとハガキになる
ここまでやって保存すれば後はOKだが、ここまで辿り着くのが至難の業 それってハガキだけの話しか？
A4やB5でもレター以外は同じだろう？
Writerでも簡単に用紙を選べないのかよ。
もう、LibreOfficeはレター圏限定のオフィスアプリで良いよ。 デフォルトがレターなんで、仰るとおりだよ
Calcはそんなことないんだけどね linux にしたってデフォルトがA4なだけで、用紙設定のバグは同じだから、例えばB5を使おうと思えば面倒な事になる。 Linuxにすりゃ安泰かと思いきや、そんな落とし穴があったとはｗ Writerで普段B4(トレイ1)に印刷してるんだけど、
ごく稀に何故かA4(トレイ2)で印刷するときがある(ご丁寧に縮小されてる)
キャンセルして再度印刷するとちゃんとB4で出てくる
困ったもんだ 腰を抜かすほど驚きました。wime3.6.0がリリースされていました。
もうバージョンアップはないと思っていました。
さっそくビルドをして、使用してみたところ、快調に動いています。
使用状況：emacs25.3+（野良）yc-5.2.1、scim-canna1.0.0(scim-1.4.9)
環境：FreeBSD11.1-RELEASE-p9(i386 Generic Kernel)※後述１
ports：wine-devel-3.7
pkg：ja-canna-lib-3.7p3 ※現状ではja-canna-serverへ依存せず
pkg：gmake-4.2.1
wime-3.6.0.tar.bz2
作業手順は前回（下記URL）と同じですが、手順のおさらいをします。
https://mevius.5ch.net/test/read.cgi/unix/1107211157/804-n
1. portsのWineにwimeのimm-magicパッチをあてる。
2. wimeをgmakeでビルド。※後述２
3. ATOKをWine環境下へインストール。レジストリを変更の事。
4. Wineからwimeが見えるようにwinecfgでドライブを割り当てる。
・FreeBSDの場合で、wimeのconf.mkにて変更すべき部分。
USE_CLANG?=0 → USE_CLANG?=1
FREEBSD?=0 → FREEBSD?=1
・32bitのFreeBSD(i386)で32bitのWineである場合。※後述３
WOW64?=1 → WOW64?=0
※私は、XIM、IMCONFIG、GTK、はコメント化しましたが、
それらの値は、ご自分の環境に合わせて変更してください。 ○後述２・後述３「前回記述の誤りについて」
https://mevius.5ch.net/test/read.cgi/unix/1107211157/804-n
前回、上記URLに書いた、wime-3.5.2のビルド手順において
誤りがありました。私自身の理解の浅さによる誤りでした。
「wime-3.5.2/io/Makefileの『#amd64でi386-wineを動かしているとき』
の文脈のかたまりをコメント化」と書きましたが、これは誤りです。
wime-3.5.2のconf.mkの「WINE32?=0」を「WINE32?=1」にすれば、
普通にgmakeが通ります。
当時、私は「OSが32bitなのだから、Wineは32bitがビルドされるのは、
Wineとして普通の動作だから」と、デフォルト値の「=1」を変更せずに、
迂遠な作業をしてしまいました。
今回、wime-3.6.0になって「WINE32」が「WOW64」に変更された事で
自分の誤りに気づきました。
Makefileに不備があるかのような、あらぬバグ疑いとなった
作者のthomas氏にも、私の記述を読んで一手間をかけてgmakeを
していた方々にも深くお詫びを申し上げます。
まことに申し訳ありませんでした。
ですから、今回のwime-3.6.0では、i386 Generic Kernel(32bit OS)の
場合、conf.mkの変更は、「WOW64?=1 → WOW64?=0」としてください。 ○後述１「i386 Generic Kernelと明示の理由」
「i386 Generic Kernel」と、わざわざ明示した理由を説明します。
「FreeBSDを語れ Part44」（下記URL）で、
FreeBSD amd64(x86_64bit) と FreeBSD i386(x86_32bit)でのバトルが
あり、PAE kernelの話が出ました。
https://mevius.5ch.net/test/read.cgi/unix/1496160953/930-990
この流れで、PAE kernelを試した方が、PAE kernel用のConfigFileで
『「makeoptions NO_MODULES=yes」は消えている』とレスした事から、
PAE kernelを試す方が続出し、FreeBSD i386のPAE kernelで、
4G以上のメモリが認識される事が発見されました。
※ググったところ、「makeoptions NO_MODULES=yes」がなくなっている
状況の報告は、匠の一手氏（2014年11月04日の記事）の記事が早かった
のではないかと思います。
http://uyota.asablo.jp/blog/2014/11/04/7482632
バトルと報告をきっかけに、私もPAE kernelをビルドし、
3.2Gでなく、4Gのメモリが認識されることを確認しました。
日常使用するカーネルモジュールが動き、ソフトウェアも動作する事を
確認したのですが、PAE kernelでは、唯一、Wineがダメでした。 ○後述１の続き「PAE kernelではWineがダメでした」
PAE kernelビルド前の、Generic Kernel時に、Wine環境を構築していた
場合、レジストリを使わないような小規模なWindowsのフリーソフトは
動きますし、
wime3.5.2+ATOK17（FreeBSD11.1-RELEASE-p3(i386)+wine-devel-2.15）も
動きました。
ただし、一太郎2004が動きませんでした。
プロセスは存在するのですが、起動していないかのように、画面の描画が
されないまま、LoadAverage値（値は忘れましたが、xloadが真っ黒）が
上がり続けます。killはできます。
さらに、.wineを新規生成しようと、「winecfg」をタイプすると、
正常終了せず、動作中に刺さったような挙動をします。
以下、エラーメッセージです。※レス用に改行
＞err:ntdll:RtlpWaitForCriticalSection section 0x7bcc2288
＞"loader.c: loader_section" wait timed out in thread 0058,
＞blocked by 0051, retrying (60 sec)
これを、「kill -9」で、winecfgを強制killすると、
ハードウェアリセット（いきなり、PC起動時のBIOS画面になる）がかかり、
fsckです。※再現性あり。
PAE kernelからGeneric Kernelに戻したところ、一太郎2004は動き、
winecfgも正常終了しました。
と、いう事で、「Wineは使わないから」とか、「Generic Kernelの時点で
Wineの環境構築をしてから、PAE kernelをビルドするよ」という方には
PAE kernelはよいかもしれません。 以下のスレに告知しました。じゃ、夜食を食べて来ます。
今夜も Wine で乾杯! - 21本目＠Linux板
https://mao.5ch.net/test/read.cgi/linux/1502540295/709 GJおつかれさん
一太郎13(とATOK)を持ってるから試してみようかと思ったけど、32bit版kernelじゃないとダメなのかな？ wimeのtarballを展開した「wime-3.6.0/io/Makefile」には、
「#amd64でi386-wineを動かしているとき」
「#さらにfreebsdのとき。LDFLAGSのlibX11.soのパスを
/usr/local/libから/usr/local/lib32にする。」
と条件分岐の記述がありますので、おそらく、wime自体は
amd64のi386-wineでビルドでき、動作すると思います。
現在の配布ページでは、記述が消えていますが、3.5.2の時は、
作者のthomas氏もamd64での方法を書いていました。
ただし、i386でパッチをあてたimm32.dll.soのバイナリをコピーする、
という方法で、ですが。
※以下、消えた記述の引用。レス用に改行しました。
＞FreeBSD 10.2について
＞標準のmakeではなくgmakeを使用してください。
＞FreeBSD 10 のCコンパイラはclangなので、conf.mkのUSE_CLANGも
＞1にした方が良いです。
＞GCCを使う場合はUSE_CLANGは0でもかまいませんが、
＞winegccはGCCがあってもclangを呼び出すようです。
＞コンパイルはi386の10.2で行いました。
＞atok使用時は下記のパッチ当ては必要そうです。
＞amd64ではコンパイル/リンクの仕方をよく理解していません。
＞32ビットでリンクしたいのにlibX11.soがない……結局libX11.soは
＞手作業で勝手に作り、wineの32ビット版imm32.dll.so
＞(パッチを当てたもの)はi386上でコンパイルしたものをコピーしました。
＞共有ライブラリ(32bitのlibwimeio.so、64bitのlibwime.so)を
＞1つのディレクトリにインストールしているのでLD_32_LIBRARY_PATHの
＞設定も必要です。本来はどうやればいいのか……
※引用ここまで。 ATOKの場合、Wineにwimeの「wime-3.6.0/patch/imm-magic-1.7.3」の
パッチをあてないといけないのですが（MS-IMEだと必要ないようです）、
amd64のi386-wineで >>806 のようにパッチがあてられるかどうか、
amd64環境がないので、私は試していません。
もしかしたら、昔、よく記事が書かれていた、FreeBSD界で有名な回避策の
「amd64でi386な仮想環境を作って、その中でportsをビルド」を
しないといけないかもしれません。
portsにi386-wineが追加される前（David Naylor氏の貢献の前）の状態、
ですね。
thomas氏のようにi386環境下でパッチあて済みのバイナリを、
amd64のi386-wineにコピーで持って来るのが楽ではあると思います。 今夜も Wine で乾杯! - 21本目＠Linux板
https://mao.5ch.net/test/read.cgi/linux/1502540295/247-252
上記のスレによると、IME関係の変更は、あまりなさそうなので、
一度、パッチあて済みのバイナリを作ると使い回しができそうです。
と言うか、正直に白状しますと、私は使い回しをしていました。
「pkgでWineをupgradeして、パッチあて済みのimm32.dll.soを
コピー、っと」という感じです。
ただ、今回のレスを書くにあたって、Wine3.0-rc4とWine3.7の
パッチあて対象のimm.cを比較したところ、ファイルサイズが
増えていました……。
Wine3.5までWine3.0-rc4でパッチあてしたimm32.dll.soを
使い回していましたよ……。 Inside Wine; Build - Qiita
https://qiita.com/Yutaka_Aoki/items/fcf3b315ae4af37d2cce
Wineスレで話題になった上記のサイトによると、
Wineのビルドにおいて特定のバイナリだけをコンパイルするという
方法も取る事ができるようです。
※私は試していませんが、覚えておこうメモです。
サブPCにFreeBSD i386を入れて、imm32.dll.soだけをコンパイル
したらamd64でもラクチンできるかも、というもくろみです。
USBメモリにi386システムを入れてブートしてコンパイルという
方法でもよいかもしれません。
クロスコンパイルの知識がないので、この手法を思いつきました。
Wine開発者様におかれましては、1.7.3の前の処理のimm.cに
戻して欲しいでございます。
そうすれば、amd64でも、バイナリパッケージシステムのpkgで、
お気楽にWine+wime+ATOKができそうですから……。
じゃ、朝ゴハン食べて来ます。 知り合いから教えてもらったパソコン一台でお金持ちになれるやり方
時間がある方はみてもいいかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』
3FZ41 A5のドキュメントを印刷しようとすると、プリンタがB5の用紙を入れろと頑として譲らない
calcもwriterも同じで、LibreOffice全体の問題かと思ったが、firefoxからA5を指定しても同じだった
どうやらNPDLドライバの問題ぽい ghostscriptのNPDLドライバって大体大丈夫なんだけど、
ちょっと変わった使い方を試みると、細かい部分でダメだったりするんだよね
まあghostscriptに限った話じゃないんだけど LibreOfficeのマクロで、firefoxに表示されている文字列を取得って出来そうですかね？
WindowsでExcel+IEの組み合わせは出来るみたいですけど 以前のレスはこちらです。ご無沙汰しております。例のwime君です。
https://mevius.5ch.net/test/read.cgi/unix/1107211157/804-813
https://mevius.5ch.net/test/read.cgi/unix/1107211157/835-844
「wime君」だと製作者と誤解されるかもしれないので、
今回から「FreeBSDでwimeを使っている君」にします。
すでに、このスレに書いたと思っていたのですが、ファイルを
整理中にレスをしていない事に気づきました。
やや古い内容になってしまいましたが、レスをする事にします。
※レスを書くのは、自分より高スキルのFreeBSD業界のwime使用者が
あらわれて、高スキルな助言がもらえないものか、という願望が
あるためです。ググっても自分のレスばかりで哀しい……。 ○FreeBSDでのWineの基礎知識
Wineの対応する「bit」は動かしているOSの「bit」と同じです。
Linux/*BSDが32bit版の場合、Wineは32bit版しかmakeできず、
32bitのWindowsプログラムしか動かせません。64bit版も同様です。
16bitコードのあるWindowsプログラムは、大昔、Wineで動いていた
ようですが、少し前のバージョンから、その処理はカットされ、
現在は「DOSBox」を呼び出して動かしているようです。
Linuxでは、64bit版Linuxの64bit版Wineで、Wineに渡す環境変数で、
32bit版Windowsプログラムを動かしているようです。(以下URLなど)
https://qiita.com/rYamashita1012/items/37e3ed22b3e9278f2250
ですが、FreeBSDでは、64bit版Wineで、同様の手順で、
32bit版Wineの「~/.wine」を生成しようとすると、固まるというか、
刺さります。
WineHQ公式の、https://wiki.winehq.org/FreeBSD には、
「The problem is that it still doesn't support WoW64,」
などとありますし、やはり、64bit版FreeBSD(amd64)で、
32bit版のWindowsプログラムを使いたい場合は、
i386-wineを使うしかないようです。 ○FreeBSDのi386-wineの状況
i386-wineは、Wine本家に追従してVersionUpしないのかな、と
思われる方もいたようで、ググると英語フォーラムなどでの
質問などが引っかかります。
コミッタの方を心配していたのですが、どうやら、お元気であり、
飽きたわけでもなく、FreshPortsによると、FreeBSDが12.0Rに
なった時点で、develの場合、Wine3.3(2018/11/02)から、
Wine3.20(2018/12/10※FreeBSD12Rリリース後)、さらに、
Wine4.0.r1(2018/12/13)、と、二度、UpdateしてWineHQ本家に
追いつきました。
が、また、バージョンアップは止まったようで、そのままです。
どうやら、FreeBSDのMajerVersionRelease時に、PortsTreeを
更新し、その後は、次のMajerVersionReleaseまで放置、という
スタンスのようです。
どうしてもi386-wineがWineHQ本家に追従してほしい場合は、
portsに頼らずに、ググるとよく引っかかる古い記事の例の
ようにjailで、amd64の中にi386環境を作るなどの方法を試すか、
かなり古いレスですが、以下のような方法が楽かもしれません。
FreeBSDを語れ Part37
https://peace.5ch.net/test/read.cgi/unix/1390323139/91-92 ○FreeBSD12.0-RELEASE(amd64)＋i386-wine＋wime4.0.0
さて本題の、FreeBSD12.0R(amd64)＋i386-wine＋wime4.0.0
での報告です。
portsからmakeする根性はないので、pkgベースですが、
FreeBSD11.2Rの時点で、FreeBSD(i386)の32bit版Wineから、
FreeBSD(amd64)の、i386-wineに移行しました。
特筆することもなく「そのまま」という感じです。
i386-wineは、32bitバイナリなファイル群のWineなんですね。
※i386なpkg版のWineを手作業で展開すれば、amd64でもラクチンに
最新追従することができるかもしれません。
さて、i386-wine-devel(4.0r1)＋wime4.0.0(※注１)＋ATOK17
は普通に動きました(※注２)。
私の場合、他のトラブルがあったのですが(※注３)。
※注１
wime4.0.0のリリースは知っていたのですが、FreeBSD(i386)な
32bitな実機を用意する必要があり、報告が遅くなりました。
「仮想環境で」とも思いましたが、大昔にQemuを使って以来、
仮想環境にはうといので、「実機で」という発想になりました。
amd64では、wime4.0.0のgmakeが通らず、makefileの修正場所も
分からないので、i386の実機を用意してwimeをgmakeし、
さらにwimeのパッチをあてたWineのimm32.dll.soも、32bitな
ものを用意しないといけないので、imm32.dll.soのためだけに、
i386機で32bit版Wineを、portsからmakeし、amd64上のi386-wineに
wime4.0.0と、imm32.dll.soをコピーで持って来ました。
※imm32.dll.soの配置場所は
「/usr/local/lib32/wine/imm32.dll.so」。 ※注２
使用状況：emacs26.1＋yc-5.2.1、scim-canna1.0.0(scim-1.4.9)
OS：FreeBSD12.0-RELEASE-p3(amd64)
pkg：i386-wine-devel(4.0r1)／i386-wine(3.0.4)
wime-4.0.0.tar.bz2(2018年8月5日)
※http://www.venus.sannet.ne.jp/thomas/wime/
※注３
FreeBSD12.0R(amd64)＋i386-wine(3.0.4)＋wime4.0.0＋ATOK17
の環境で使っていると不思議な挙動に気づきました。
一例ですが、以前に確定完了した「目が」を「眼が」にしたく
「めが」とタイプし、候補表示を開くと、「目が」「眼が」との
候補順表示を期待しますが、「目」「眼」の候補しか
表示されません。それで、「眼」を選んで確定した場合、
「が」が、確定文字に残らず「眼」だけになります。
変換候補の表示通りの挙動ではあるのですが。
状況としては、以下のURLを参考にできます。
https://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q14158985634
http://support.justsystems.com/faq/1032/app/servlet/qadoc?QID=033195
上記URLで示された画像の淡色灰色表示の「かな」が
表示されていない状況です。
つまり、語幹より後の「かな」が表示されていないのです。
※ATOK公式の画像にある「こおり」は「氷り」「氷」どちらも
候補に表示され、確定後も「り」は残るが、「り」は、
「語幹より後の存在」というよりは、表記の違いのためでは
ないか、と思います。 ○「※注３」の語幹より後の「かな」が表示されない問題の続き
ATOKのプロパティをさわっても直りませんでした。
それで、wime4.0.0以前は、なんともなかったので、
wime4.0.0から、wime3.6.0に戻してみると、語幹より後の
「かな」は普通に候補表示され、確定後も、かな部分の欠落は
ありませんでした。
今は、i386-wine(3.0.4)＋wime3.6.0＋ATOK17の環境で大満足で
使っています。
Cannaにも、ATOKの設定にも、詳しいわけではないし、
wimeのドキュメントを読んでも、Cannaなどの仕組みを理解して
いない部分があるので、wime4.0.0の仕様変更のせいなのか、
「古すぎるATOKのお前の環境」のせいなのか、判断がつきません。
作者のthomas氏に報告すべきでしょうが、私的には、thomas氏は
神様なので、報告はこわいというか、おそれ多くてできません。
説明されても理解できない部分が出てくると思います。 ○i386-wine-devel(Wine4.0r1)＋一太郎2004
Wine4.0r1では、一太郎2004が、
「Failed to launch server application.」と言われ、
動きませんでした。
winecfgでの「Application settings」で、WineがWindowsプログラム
に返すWindowsのバージョンを、WindowsXPや、Windows7など、
すべてのパターンで試しましたが、ダメでした。
公式のFAQ(一太郎2007の説明でしたが)も見ましたが、
「再インストール」などと書かれており、
「いや、今インストールしたばかりなんですけど」という状況
(インストーラは動きました)で、Wine4.0で一太郎2004を
動かすのはあきらめ、Wine3.0.4に戻しました。
Wine4.0以降は、一太郎2004が動かないのではないか、と、
嫌な予感がしたので、情報収集をして、virtualbox-ose-5を
導入し、手持ちのWindowsを動かしました。
「何を今さら」と思われるでしょうが、すごいの一言です。
ヌルヌル動きます。ほぼ、ホストOSの実機のパワーが、
そのままゲストOSに伝わっている感じです。
Qemuでオロオロしていたのは何だったんだろう、と思いました。
Wineでも一太郎が動いて欲しいのですが、まあ一安心です。
じゃ、夜食を食べて来ます。 >>851
Wineの16bitコードの説明が、不正確なので補足します。
16bitリアルモードや、仮想8086モードを使う、Windows3.x対応の
Windowsプログラムの場合のみ、DOSBoxが必要、のようです。
今夜も Wine で乾杯! - 22本目
https://mao.5ch.net/test/read.cgi/linux/1540015268/832-839 一太郎の季節です。試用版、体験版、という言葉を思い出し、
一太郎2020体験版を、Wineで試してみました。
自分の環境だと、Wineで設定をしても、日本語入力(SCIM-Canna)は
できないし、Wineで稼働するWindowsプログラムで日本語入力を
する気も薄いので、文書整形、表示、印刷はどうか、そして、
昔から、普通に、横書表示と横書印刷は正常にできているので、
おもだって、縦書表示と縦書印刷はどうだろうか、という視点です。
OSは、FreeBSD12.0R(amd64)です。まだ12.1Rにしてません。ごめん。
あっ、ATOKの無償試用版は、メールアドレス登録が条件のようで、
JustMyShopから一太郎色の老眼鏡やパンツの案内が届きそうなので
試していません。
○i386-wine3.0.4(Application_settingsはWindows10)
●一太郎ビューワ(2019)※縦書の一太郎のバイナリ文書を開いた
・インストール：OK
・本体起動：OK
・縦書表示：OK。約物が寝ずに正常表示。
・縦書印刷：「約物」が一文字づつ寝る。
＊短評
大昔、OpenOffice/LibreOffice3.x系のPortable版を、Wineで
動かしたところ、Wine1.7.11以降は、「約物」も問題なく
縦書表示、縦書印刷でき、Wineの機能が退化した場合も、
「約物」が一文字づつ寝る(横表示)程度で、
縦書表示、縦書印刷はできていたので
(約物が寝ているのでダメではありますが)、
Wine側か一太郎側かは不明ですが、進化していると思います。 ○i386-wine3.0.4(Application_settingsはWindows10)
●一太郎2020体験版(Taro30)※縦書の一太郎のバイナリ文書を開いた
・インストール：OK
・本体起動：OK
・縦書表示：OK。約物が寝ずに正常表示。
・縦書印刷：「約物」が一文字づつ寝る。
＊短評
・表示は一太郎ビューワ(2019)よりキレイな感じに見えた。
・昔から存在する一太郎添付のフォント(DF/DHP/JSフォント)で
読点が左側になる表示がなくなっていた。
・縦書の一太郎バイナリ文書を開く時、おそらくWindows10用に
一太郎側で個別パッチしたっぽい(Windows10では縦書時に
約物が横に寝るという動作をする)メッセージ(※注)が
出るが、Windows10用の機能を使っても使わなくても、
約物の表示は正常。
※注(引用メッセージの改行位置は執筆者独自)
「縦組時の約物をフォント優先で表示しますか？
フォント優先で表示すると、三点リーダ（…）やダッシュ
（−）などが常に縦向きに表示されるようになります。
設定は【ツール−オプション−オプション】で
元に戻すことができます。YES/NO」※引用ここまで。
・フォントごとに約物が寝るものと寝ないものに分かれる。
表示で寝ても寝なくても印刷では寝る。
・文書校正機能を使うと、Wineのエラーボタン
(Internal_application_error)が出続けるので
killするしかなくなる。 ○i386-wine4.0r1(Application_settingsはWindows10)
一太郎ビューワ(2019)、一太郎2020体験版とも、i386-wine3.0.4で
インストールしたので、インストーラの挙動は不明だが、
体験上(※>>856)、Wineへ正常にインストールできるものと思われる。
本体の起動そのものはできる。
テキストプルダウンのメニューつきのWine添付のnotepadのような
味気ないウィンドウが開くが、そのプルダウンメニューから
一太郎縦書バイナリ文書を開くと、Wineが「Program_Error」の
メッセージウィンドウを出す。
killせずに正常に終了できる。
現状、Wine4.0では、一太郎ビューワ(2019)、一太郎2020体験版は
使えない。
※かっこよさ演出の、プログラム名のスプラッシュ表示すらなく、
味気ないウィンドウで起動する時点でおかしいのかもしれない。 LibreOffice、充分使えてるけど
現状の不満はいずれもwriterで、
・差し込み印刷が出来ないこと
・罫線を使うと崩れやすいこと
くらいかな 無人の砂漠で書いているような気持ちでしたが人がいたんですね。
一安心。よかったよかった。
>>860 への追記です。
「現状、Wine4.0では、一太郎ビューワ(2019)、一太郎2020体験版は
使えない。」と書きましたが、執筆者の確認不足でした。
twitterの@sagawa_aki氏によると、一太郎2019は、Wine4.2以降で
動くそうです。
https://twitter.com/sagawa_aki/status/1096742606963335168
もともとWineはWindowsゲームをターゲットにしている感じがあり、
ビジネスソフトへの配慮が薄い、と感じていましたが、ちゃんと
配慮されているようです。
sagawa氏って、あのsagawa氏なのですね。
Wine1.7.11での縦書き対応、本当にありがとうございました。
今夜も Wine で乾杯! - 18本目
https://engawa.5ch.net/test/read.cgi/linux/1347464833/398-n
https://engawa.5ch.net/test/read.cgi/linux/1347464833/939-n
広報部Ｋの日常: wine 1.7.11で縦書き
https://kouhoubk.blogspot.com/2014/02/wine-1711.html
広報部Ｋの日常: wine 1.7.13で縦書き
https://kouhoubk.blogspot.com/2014/02/wine-1713.html
https://twitter.com/5chan_nel (5ch newer account) >>862
もう1つあった
やはりwriterで、
・縦書きが崩れやすい
表示だけで、スクロール等で再描画されると直るが、それでもズレている
印刷すると問題なし ■ このスレッドは過去ログ倉庫に格納されています
