Hatena::ブログ(Diary)

風柳メモ このページをアンテナに追加 RSSフィード Twitter

2014-07-11

「Jコミ」改め「絶版マンガ図書館」の初期不具合等

本日、Jコミが「絶版マンガ図書館」としてリニューアルされましたが、大幅な改定を行ったためか、ざっと見たところでも不具合等が目につきましたので、覚書を兼ねて。

まぁ、徐々に改善されていくのだと思いますが(初回の分は、Jコミ情報室!さん及び赤松氏に報告済み。その後は随時お問い合わせ等でも報告)。

→対応されたもの・新たに見つけたもの等を随時更新。

Web 版

不具合
No.不具合内容対応備考
1マイページの本棚で「本棚から削除」が出来ない。削除できるようになった(2014/07/12)。 一旦消えたように見えても、ページをリロードすると削除できていない。
サーバとの通信が行われていないように見える。
2シリーズ作品において、巻数順にソートされていないものがある。
作品一覧や、作品詳細ページのシリーズ作品の案内、RSS等
ソートされるようになった模様(2014/07/13)。 例:ハイスクール!奇面組 スクリーンショット
全10巻以上の長編
3作品詳細ページの「著作者の作品案内」に何も表示されない。「著作者の作品案内」欄がなくなった(2014/07/12)。
4http://r18.zeppan.com/ の右下のランキングが表示されない。表示されるようになった(2014/07/12)。500エラーが発生している模様。
5http://zeppan.com/ の右下のランキングが総合ランキングしかない。一般・成人向け共に「総合ランキング」のみに統一された(2014/07/12)。R18の方は7日間ランキング・30日間ランキングもある→無くなった(2014/07/12)。
6「作品一覧」などで、画面を下にスクロールした際に継ぎ足された作品については、「本棚に追加」「本棚から削除」ができない。継ぎ足された作品に関しても、追加・削除共にできるようになった(2014/07/14)。
7マイページの本棚にXSS脆弱性有り。報告分に関しては対策された(2014/07/13)。2014/07/13に「お問い合わせ」から報告。
8「作品一覧」などで、最初に表示されたり、継ぎ足されたりする作品数が50個だったりたまに10個だったりで一定しない。改善されたように思える(2014/07/14)。 2014/07/14に「お問い合わせ」から報告。
9マンガ検索フォームにXSS脆弱性有り。報告分に関しては対策された(2014/07/15)。2014/07/14に「お問い合わせ」から報告。
前日までは存在しない脆弱性だったはず、改修過程で入り込んだ模様。
10タイトル50音順一覧に出てこない作品がある。報告分に関しては対策された模様(2014/07/15)。2014/07/15に「お問い合わせ」から報告。
ら行を最後までスクロールしても、「LoVe/EGOISTIC」(著作者 ぐりすぐり)が表示されない。
11リニューアル後に掲載された作品で、著作者名が表示されないものがある。対応された模様(2014/07/15)。蓬萊学園の冒険!!(未報告、JComi_Updateのツイートで気づいてはいたが、そういうものだと思っていた)→2014/07/15対応済み。
おしえて♡お姉さん (2014/07/15、ツイートで報告)→2014/07/15対応済み。
その後も発生している(データベースへの登録ミスか?)。
12旧Jコミの「Jコミで印刷できるってよHD」のPDFが(再)ダウンロードできない。対応された模様(対応日不明、2014/07/25以前)。 503エラーでアクセス不可(2014/07/18)。
2014/07/18に「お問い合わせ」から報告。
2014/07/19時点の回答:サイトリニューアルに伴い、一時的に閉鎖中、近日中に再オープンとのこと(「現在、このページはメンテナンスを行っております。後日改めてアクセス下さい。ご迷惑をおかけてしておりますが、よろしくお願い申し上げます。」表示になった)。

-総作品数が一覧で表示される作品数と一致しない。 2014/07/14に「お問い合わせ」から報告。
■一般向け作品
総作品数:1,475
新着公開作品:1416件
最新アップロード作品:54件
※5件少ない。
■成人向け作品
総作品数:272
新着公開作品:261件
最新アップロード作品:11件
※こちらは一致。

要望等
No.現状要望対応備考
1Jコミではシリーズ作品をまとめたページがあったが、これがなくなり、一覧表示などでも1巻ずつ表示される。
このため、特に全10巻以上の長編等では非常に見通しが悪いように感じられる。
一覧・検索表示では、シリーズ作品はまとめてひとつとして欲しい(好みの問題かもしれないが…)。赤松氏:「ニコ動のように、同じ作品でも画質の違うバージョンが複数上がってくる可能性があるため、巻ごとの管理になりました。 」 現状でも、作品詳細ページには、シリーズ作品がまとめて表示はされる。
2「本棚に追加」が単巻ずつしかできない。シリーズものについてはまとめて追加したい。
3既存のJコミ作品ページ等へのリンクが全て絶版マンガ図書館のトップページにリダイレクトされてしまう。既存のJコミの各作品へのリンクは、当該作品のページへリダイレクトして欲しい。 各作品の旧リンクがリダイレクトされるようになった(2014/07/12)。 作者の方等にも負担になっている。(参考
4Jコミで有志の入力による作品データが存在したが、これがなくなっている。
旧作品ページのキャッシュで、「>> 作品データを見る」をクリックしたときに出てきたもの。
既存の作品データについては予めWikiに反映しておくなどの配慮が欲しい。 既存の有志の方のモチベーションを下げてしまう。(参考
赤松氏:「絶版マンガ図書館では、wikipediaに準じた様式で書いて欲しい希望はあります。編集ツールもwikipedia準拠になっています。IPアドレスなども残ります。これまでとは結構違いますのでお気を付け下さい。しばらく様子見することをお薦め致します。 」
5サムネイルをクリックしても作品詳細ページに移行しない(マウスオーバ→作品詳細ページへをクリックする手順が必要)。サムネイルクリックでも作品詳細ページへ移行して欲しい。対応された(2014/07/15?)。要望として認識はされており、いずれ直されるとのこと(2014/07/14・参考

Androidアプリ

使用機種:WX04K(Android 4.1.1)、旧Jコミ用JComi Viewer+はアンインストール済み。

不具合
No.不具合内容対応備考
1DLのためにログインしようとすると、「ページの読み込み中…」が断続的に表示される等して、ログイン入力ができず、ダウンロードできない。ログイン&ダウンロードが正常に出来るようになった(2014/07/12)。 2014/07/15現在、まだたまに同様の現象が発生してログインできないこともある。サーバ側の負荷などの問題なのか?
2R18の方で、DLを選択しているのに、(「ページの読み込み中…」が断続的に表示される等した後で、リダイレクトされて(?))PC版の画面が表示されて正常動作しない。ログイン&ダウンロードが正常に出来るようになった(2014/07/12)。同上。

2014-06-15

32ビット環境だと2GBを超えるファイルサイズが正常に取れないのか…

PHP_INT_MAX = 2147483647 = 0x7FFFFFFF となっている環境だと、

注意: PHP の数値型は符号付整数であり、 多くのプラットフォームでは 32 ビットの整数を取るため、 ファイルシステム関数の中には 2GB より大きなファイルについては期待とは違う値を返すものがあります。

PHP: filesize - Manual

のように、filesize() の返り値が保証されないということを今更ながらに気付く。

64ビット環境でテストしていたから、32ビット環境で動かしてみてしばらく悩んでしまった。

やむを得ず、代用関数を考えて見る

<?php
function    get_filesize($filepath) {
    $filesize = '';
    for (;;) {
        if (!file_exists($filepath)) break;
        exec("/usr/bin/wc -c < {$filepath}", $output, $return_var);
        foreach ($output as $line) if (($filesize = trim($line)) !== '') break;
        break;
    }
    return $filesize;
}   //  end of get_filesize()

"wc -c"の結果を取得して、文字列で返しているだけ。ファイルが存在しない場合等は ""(空文字列) が返る。


BCMathが有効な環境であれば、使えるかな?

RHEL6.3で、HTTP GET時に5分以上受信データがないとだんまりになる

現象

とあるレンタルサーバ(telnetやsshは未サポート)上のデータをローカル(RHEL6.3 サーバ)上に定期的にバックアップを取る必要があり、ファイル数が多くFTPだと時間がかかって仕方がないので、

  1. レンタルサーバ上のPHPスクリプトを呼び出し、tar コマンドにより全ファイルをアーカイブ。
  2. アーカイブした tar ファイルを FTP でダウンロード。

という方法を取っていたのだが、ある時点から、正常にバックアップが取れなくなってしまった。


調べてみたところ、

  • 1. で、HTTP GET Request 後に、一定時間(5分)以上受信データが無い状態が続くと、HTTP クライアントがその後のデータを受信しないままフリーズしてしまう。

状態であることがわかった。


ちなみに、HTTP クライアントには wget を使用していたが、

  • 同一バージョンの wget を使用しても、個人持ちの CentOS 6.5 上ではフリーズせずに問題なく完了。
  • 当該 RHEL6.3 サーバ上では、wget 以外の方法であっても、同様の現象が発生してしまう。

RHEL6.3 サーバ上で使用している socket 関連の共有ライブラリ(あるいはその設定)に問題があるのであろうところまでしかわかっていない。


どなたか、このような場合の対策をご存じの方がおられたら、教えてほしい。

もっとも、5分以上もデータが無い状態が続くと、そもそも他のレンタルサーバとかだと Apache とかのタイムアウトの方でひっかかってしまう気がしなくもないので、どちらにしてもレンタルサーバ側の処理も見直す必要があるのだろうけれども。


再現方法

次のようなPHPスクリプトをレンタルサーバ上に設置し、

/test/wait.php
<?php
$WAIT_MIN = 5;  //  <=4:OK, >5:NG

if (isset($_GET['wait']) && is_numeric($_GET['wait'])) $WAIT_MIN = intval($_GET['wait']);

$WAIT_SEC = $WAIT_MIN * 60;
$WAIT_UNIT_SEC = 10;
$WAIT_COUNT = (int) ($WAIT_SEC / $WAIT_UNIT_SEC);

set_time_limit($WAIT_SEC * 2);

function    echo_flush($str) {
    echo($str);
    ob_flush();
    flush();
}   //  end of flush_output()

ob_start();
header("Content-Type: text/plain; charset=utf-8");
ob_end_flush(); // バッファフラッシュ&バッファリングをOFFに

echo_flush("wait {$WAIT_MIN} minutes ({$WAIT_SEC} seconds) ...\n");

for ($ci=0; $ci < $WAIT_COUNT; $ci++) {
    sleep($WAIT_UNIT_SEC);
    //↓の行を有効にして、10秒毎にデータを送信するようにすればクライアント側でフリーズしない
    //echo_flush(sprintf("%5d sec.\n", $WAIT_UNIT_SEC*(1+$ci)));
}
echo_flush("done.\n");

exit(0);

// ■ end of file


RHEL6.3 サーバ上で wget を実行すると、

$ wget "http://example.com/test/wait.php?wait=4" -q -O -
wait 4 minutes (240 seconds) ...
done.

のように、4分までは問題なく完了するのに、

$ wget "http://example.com/test/wait.php?wait=5" -q -O -
wait 5 minutes (300 seconds) ...

5分からは(wget側でタイムアウトするまで)だんまりになる。


また、telnet で試しても、

$ telnet example.com 80
Trying xxx.xxx.xxx.xxx...
Connected to example.com.
Escape character is '^]'.
GET /test/wait.php?wait=4 HTTP/1.0
User-Agent: telnet
Host: example.com

HTTP/1.1 200 OK
Date: Sun, 15 Jun 2014 00:00:00 GMT
Server: Apache
Connection: close
Content-Type: text/plain; charset=utf-8

wait 4 minutes (240 seconds) ...
done.
Connection closed by foreign host.

のように、4分までは問題なく完了するのに、

$ telnet example.com 80
# : (中略)
GET /test/wait.php?wait=5 HTTP/1.0
# : (中略)
wait 5 minutes (300 seconds) ...

5分からは、この状態でだんまりになる。


暫定対策

レンタルサーバ側のPHPスクリプトで、次のような関数を使って tar コマンドをバックグランドで呼び出した後、処理が終わるまで一定時間毎にポーリングし、何らかのデータを出力するようにしている。

<?php
function    exec_nowait($cmdline, &$outfile, &$errfile) {
    $outfile = tempnam('./', 'OUT_');
    $errfile = tempnam('./', 'ERR_');
    $cmdline = "{$cmdline} >{$outfile} 2>{$errfile} & echo \$!";
    $pid = null;
    exec($cmdline, $output, $rcode);
    foreach ($output as $line) if (($pid = trim($line)) !== '') break;
    return $pid;
}   //  end of exec_nowait()

$pid = exec_nowait("tar cvf backup.tar /path/to/target", $outfile, $errfile);
while ($pid) {
    sleep(10);
    if (/*バックグラウンド処理のチェックを行い、終了していたら*/) break;
    echo(date("Y-m-d H:i:s") . "\n"); // データ出力
    ob_flush();
    flush();
}
// この辺で後処理を入れる
unlink($outfile);
unlink($errfile);

バックグラウンド処理の終了チェックは、psコマンドが使える場合は、

<?php
function    get_proc_dict() {
    $proc_dict = array();
    $cmd = "/bin/ps -A -o pid= -o comm=";
    $fp = popen($cmd, "r");
    while (($line=fgets($fp))!==false) {
        $line = trim($line);
        $parts = explode(' ', $line, 2);
        $proc_dict[$parts[0]] = $parts[1];
    }
    pclose($fp);
    return $proc_dict;
}   //  end of get_proc_dict()

function    get_proc_name($pid) {
    $proc_dict = get_proc_dict();
    return isset($proc_dict[$pid]) ? $proc_dict[$pid] : null;
}   //  end of get_proc_name()

// while ループ内のチェック部分で、if (!get_proc_name($pid)) break;

のような関数を用意して使うのがよさそう。


ps コマンドが存在しない場合は…tar の標準出力($outfile)をチェックして、例えばサイズが変わらなくなったら終了、とか。


関連?

RHEL5.1でFTPのダウンロードが正常に完了しない場合がある? - 風柳メモ

2014-06-09

【近傍ツイート検索】(twDisplayVicinity):Google Chrome拡張機能版を公開

【近傍ツイート検索】特定ツイート前後のタイムラインを表示するユーザースクリプト

の、Google Chrome専用版(拡張機能)を公開


本体スクリプトはユーザースクリプト版と同一であるため機能的な違いはないが、表示オプション等が設定画面から変更可能になっている。


インストールの前に

既にユーザースクリプト版がインストールされている場合、Google Chromeの拡張機能(chrome://extensions/)を開き、

f:id:furyu-tei:20140609184941p:image

twDisplayVicinityを削除。

Tampermonkey等の拡張機能経由でインストールしている場合は、それぞれの拡張機能のアンインストール機能で削除。


インストール方法

  1. Chrome ウェブストア - twDisplayVicinityからインストール開始。
    f:id:furyu-tei:20140609184942p:image
    ダイアログ右上の方にある[+ 無料]ボタンをクリック。
    これ、初見だとインストール用ボタンだと判りづらいと思うのだけれど、自分だけ?

     

  2. 『新しい拡張を機能の確認』ダイアログが表示されたら、
    f:id:furyu-tei:20140611013357p:image
    [追加]ボタンをクリック。

オプション設定

  1. Google Chromeの拡張機能(chrome://extensions/)を開き、twDisplayVicinityの
    f:id:furyu-tei:20140609184944p:image
    “オプション”リンクをクリック。

     

  2. オプション画面が開いたら、お好みに応じて各種オプションを変更。
    f:id:furyu-tei:20140611012152p:image

使い方

Twitterの個別ツイート、もしくは、タイムラインを開き、名前/日付の右側に表示される“近傍”リンクをクリックすると、

f:id:furyu-tei:20140609190758p:image


別タブ/ウィンドウで当該ツイート前後のその人のツイートが表示される。

当該ツイートが画面に出現するまで自動でスクロール。

f:id:furyu-tei:20140609190759p:image


デフォルトではその人のタイムライン上から検索するが、この場合は最大で(最新発言から数えて)3200件までしか遡れない。
上記方法でツイートが表示されない場合は、(デフォルトでは)[Shift]キーを押しながら“近傍”リンクをクリックすることで、Twitterの検索機能の結果表示から探すこともできる(ただしRTは表示されず、精度も落ちる)。

2014-06-06

乙佳佐明(☆よしみる)著「ココロノミカタ」単行本がJコミより届く。

いえ、届いたのは先週なんですけれどね(苦笑)。先ほどやっと中身を確認できたので。

ちなみに、クロネコメール便で届きました。

発注日2014/05/17(土)
発送日2014/05/22(木)
投函日2014/05/26(月)


作品紹介・感想など

メガネと左目の下のホクロが可愛い*1“旅の花屋”『ココロさん』と、相棒であるお猿の『ミカタさん』の旅情物語。

基本は一話完結形式の全11話+番外編1話。

「旅」は“場所”だけではなく、明治〜平成という“時代”も渡ります。


不思議なことに、時代を経ても変わらないように見える、ココロさんとミカタさん。

ですが、それ以外には特に(魔法を使ったりといった直接的な)不思議の描写があるわけではなく、旅先で出会った人々との交流が主体です。でもその交流を通して、人々が幸せになっていく、その様子を見たココロさんも幸せになる、という軌跡と奇跡の物語。

私的には、一見、ココロさんとツーカーに見えて、実は全然違うこと(主に食欲方面)を考えているミカタさんがツボ。



既にPDF版を読んではいましたが、改めて紙の単行本で読み返しました。

うん、やっぱり(少なくとも今の段階では)漫画は紙で読むのがいいですね。

ということは、まだ当分は蔵書が増え続けるわけかぁ。そろそろ、万のオーダーに届きそうなんだけれども。


単行本の出来はどんな感じかというと…

今回注文したのは、『表紙マット加工+無線綴じ』でした。

f:id:furyu-tei:20140607120247p:image

大きさは、ほぼB6サイズ(実測:128mm x 181mm、厚さ11mm)。背表紙にタイトルと著者名が印刷されています。

もちろん、PDF版と比べると画質もかなりよくなっています。

PDF版(200%表示)単行本(300dpiでスキャン&166%拡大)
f:id:furyu-tei:20140517175441p:imagef:id:furyu-tei:20140606002231p:image

f:id:furyu-tei:20140605233823p:image

裏表紙には、著者のサイン(印刷)付。


他に印象的だったのは「(モノクロページの)紙質がいい!黒が綺麗!」ということ。

βの頃から変わっていないとすると、印刷業者は製本直送.comだと思われるの*2料金シミュレータのページから推測するに、本文用紙は「ホワイトしらおい」(104.7グラム/平方メートル)あたりなのでしょうか。

画質もよいので、ミカタさんの台詞のような小さな手書き文字でもくっきりときれいに読めます。

カラーページがモノクロになってしまうのは残念ではありますが、まぁこれは仕方ないです(モノクロ化されたカラーページでもそれなりに綺麗ではあります)。

IRC用ダイスボット「ボーンズ&カーズ」(BCDice)のtestをLinux(CentOS 6.5)上で動作させるための覚書

先日、IRC用ダイスボット「ボーンズ&カーズ」のコマンドが使用できるTwitter用botを作成した。

IRC用ダイスボット「ボーンズ&カーズ」のTwitter版を試作: 風柳亭

これは、Diceだよ!TwitterのStreaming APIを試用するための習作bot)を流用して作ったこともあり、基本Pythonで動作している。

ダイスロールは、Pythonの子プロセスとしてRubyスクリプト(cgiDiceBot.rb)を呼び出し、返ってきた結果(標準出力)を加工してツイートしているため、実はBCDiceのソースコードには全く触っていなかった。


ただ、しばらく運用しているうちに、いくつか問題が判明したため、最小限のパッチを当てる必要が出てきた。

追記

Pull RequestしていたものがBCDice/どどんとふにも反映された模様。

Ver2.02.16 2014/06/18 ? fcc774e ? torgtaitai/BCDice ? GitHub

どどんとふ@えくすとり?む - 「どどんとふ」Ver.1.45.01リリース


問題点

No.問題点原因対策
1cgiDiceBot.rb実行時、 extratablesが反映されないsrc下にextratablesが必要*3src下にextratablesへのシンボリックリンク作成
2diceBot下に非公式ボットを置いた際、cgiDiceBot.rb実行時、 DiceBotLoader#loadUnknownGameで読み込まれないsrc下にsrc_bcdice/diceBotが必要*4src下にsrc_bcdiceディレクトリ作成&src_bcdice下にdiceBotへのシンボリックリンク作成
3src/test.rbでエラー発生ruby.exeをコールしている/usr/bin/rubyへのシンボリックリンク(/usr/bin/ruby.exe)作成
4src/test/test.rbでテストが一つも実行されないtestData.txtをパースする際、\rが残ってしまっている(\r\nではなく\nで分割しているため)testData.txt読み込み時、\r\nを\nに置換
5src/test/test.rbで標準のテストが一部失敗するtest.rbが../../src_diceを基準にしている*5../../に、srcへのシンボリックリンク(src_bcdice)作成
6src/test/test.rbのエラー出力が文字化けする結果がShift-JISで出力されているUTF-8出力に変更(Windows環境下とで場合わけ)

なお、これらの問題点は、

ということが発生要因ではないかと思われる。


パッチ

BCDiceを展開したディレクトリ(BCDice-master等、srcの一つ上)に以下の patch.sh 及び test.diff を置き、patch.sh を実行。

BCDice Ver2.02.15 2014/04/29 で動作確認。

patch.sh
#! /bin/bash
CURDIR=`pwd`
if [ ! -e /usr/bin/ruby.exe ] && [ -e /usr/bin/ruby ]; then
  sudo ln -sf /usr/bin/ruby /usr/bin/ruby.exe
fi
if [ -d ./src ]; then
  if [ ! -e ./src_bcdice ]; then
    ln -sf ./src/ ./src_bcdice
  fi
  cd ./src
  if [ ! -e ./extratables ]; then
    ln -sf ../extratables/ ./extratables
  fi
  mkdir -p ./src_bcdice
  if [ -d ./src_bcdice ]; then
    cd ./src_bcdice
    if [ ! -e ./diceBot ]; then
      ln -sf ../diceBot/ ./diceBot
    fi
  fi
fi
cd $CURDIR
patch -uN ./src/test/test.rb < ./test.diff

test.diff
--- ./src/test/orig/test.rb     2014-05-28 12:56:16.929296739 +0900
+++ ./src/test/test.rb  2014-05-29 00:46:58.740404535 +0900
@@ -20,7 +20,7 @@

     resultFile = './testData.txt'

-    buffer = File.readlines(resultFile).join.toutf8
+    buffer = File.read(resultFile).toutf8.gsub(/[\r\n]+/, "\n")
     testDataList = getTestDataList(buffer)

 #    @testResultFile = open('testResult.txt', 'w+')
@@ -123,7 +123,7 @@
       log << "index:#{@testIndex}\ninput:#{@input}\nresult:#{result}\ngood  :#{@good}\nrandsText:#{@randsText}\n"
     end

-    return log.tosjis
+    return RUBY_PLATFORM.downcase =~ /mswin(?!ce)|mingw|cygwin|bccwin/ ? log.tosjis : log
   end

   def getTestDataList(buffer)

追記1:公式リポジトリへの反映方法考察

上記のパッチは(自分がRubyを知らないこともあって)『極力元のソースコードは変更しない』方向で実施したため、公式リポジトリへの反映を考慮した場合、このままだとシンボリックリンクの扱い等が問題になってくると思われる。


以下、

  • Windows と Linux 双方の対応。
  • リポジトリのディレクトリ構成は保ったまま、どどんとふBCDiceのいずれであってもtest.rbが走るようにする。

としたい場合の修正方法を検討する。


Windowsとの差分対応その1(問題点No.3)

いくつかのソースコード(test*.rb)中で、

command = "ruby.exe -Ku testPointer.rb #{ARGV.join(' ')}"

という箇所が出てくるが、'ruby.exe' だと Linux では実行時にエラーとなるため、'ruby' に置換する。


Windowsとの差分対応その2(問題点No.4, 6)

改行コード及び文字コードの問題なので、上記test.diffの内容を ./(src|src_bcdice)/test/test.rb に反映する。


パスの問題(問題点No.1, 2, 5)

どどんとふとBCDiceとで、ソースコードは共通であってもディレクトリ構成が異なっているために発生すると思われる問題。

なお、これらはWindows上でBCDice/src以下からtest.rbやcgiDiceBot.rbを動作させる場合にも発生するはず。

BCDiceの方でシンボリックリンクを作成することで対処可能ではあるが、Windowsとの共通化を考えた場合にはあまりうまくない。

一応、Windows上でも mklink コマンドでシンボリックリンクの作成は可能ではあるが。

いくつかのソース(TableFileData.rb、diceBot/DiceBotLoader.rb、test/test.rb)でextratablesやsrc_bcdiceディレクトリを参照している個所で、ディレクトリの存在をチェックし、存在しない場合にはパスを変更するような処理を入れるのが妥当か。

ソース名デフォルトPATH変更PATH
TableFileData.rb'./extratables''../extratables'
diceBot/DiceBotLoader.rb'./src_bcdice''../src'
test/test.rb'../../src_bcdice''../../src'

*1:なぜ衣装や他の特徴に触れない…?>自分

*2:確認したらトップページの『ご利用事例』のところにJコミが紹介されていました

*3: TableFileData.rb:40: @dir = './extratables'

*4: diceBot/DiceBotLoader.rb:4: @@bcDicePath = './src_bcdice'

*5: test/test.rb:19: DiceBotLoader.setBcDicePath( '../../src_bcdice' )

2014-05-22

「Jコミで印刷できるってよHD」で貰えるPDF版の画質に関するJコミさんとのやり取りについて

「Jコミで印刷できるってよHD」で貰えるPDF版の画質が悪くてちょっと残念… - 風柳メモ

を書いた後、赤松氏はじめJコミの方とやり取りした内容のうち、公開できる部分に関して記述します。

要点は、

  • 現状配布しているPDFは交換すべき瑕疵ありとは判断しない(作品閲覧の目的には十分な品質である)。
  • ユーザからの要望を含む、各種要件を総合的に判断した上で、バランスの良い技法・配布方法を検討している。
  • 今後も改修・検討は引き続いて行われる。

ということになると思います。


Twitterでのやり取り

からの一連のやり取りを参照。


メールでのやり取り

記事およびTwitterでのやり取りを示したうえで、当方の希望として

  • 「Jコミで印刷できるってよHD」を発注時に頂けるPDFの画質は、せめてカヲルやJComi Viewer+における高解像度版(JPEG・827×1170)相当の画質であって欲しい。
    ※欲を言えば、印刷用に使用されるデータ(300dpi)であれば大変うれしいのですが。
  • 以前購入させて頂いた「Jコミ | JコミFANディング - 八神健PDFセット」内のPDFも調べてみると(Web/JComi Vieer+の同名作品と比較して)画質が劣化しているようですのでこれも改善の上、再度ダウンロードさせて欲しい。

ということを申し上げたことに対してのご回答です。

引用許可を得た部分のみ。

法務担当者様の見解(主に「画質の良いものを再ダウンロードさせてほしい」という要望に対して)

  「Jコミで印刷できるってよHD」サービスのご購入時には、「Jコミで印刷できるってよHD利用規約」に

ご同意をいただいておりますが、同規約第11条におきまして返品・交換に関します規定がございます。

〜〜〜〜〜〜

第十一条 返品及び交換

  1 購入者は、本サービスにおいて提供された書籍及びPDFファイル等を、返品することはできません。

  4 PDFファイル等につき、当社が交換すべき瑕疵があると判断した場合には、購入者は当社に交換を請求することができます。

〜〜〜〜〜〜

弊社が11条4項にある「瑕疵」ありと判断する場合とは、作品閲覧という目的に通常必要となる程度の品質を

備えていない場合を想定しておりま す。

具体的には、ページ抜けや著しく劣化した画像などがこれに当たります。

この度の作品データにつきましては、弊社としましては11条4項に当たる瑕疵はないと判断しておりまして、

申し訳ございませんが契約上の理由での交換をお受けすることはできません。

PDF配布に関する業務のご担当者様からの見解(画像の劣化に関する件)

・ユーザーからの要望は多種多様であり、出来うる限り要望に沿う方法を検討していること。

・精度、ファイルサイズなど総合的な判断から最もバランスの良い技法、配布方法を検討していること。

・今後も改修・検討は引き続いて行っていくこと。