はじめまして．
現在，卒業論文をTeX Live 2017で書いている大学生です．
TeX Live 2017は，64bit版をWindows 10 にインストールして使用しています．
エディタはTeX Studioを利用しています．
さて，jsclasses についてですが，
\documentclass[12pt,a4paper]{jsarticle}
と指定すると，本文のフォントサイズが，12ptよりも小さく出力されてしまって苦戦中です．
\documentclass[12pt]{jsarticle}
と指定した場合と比べて，本文中のフォントサイズが小さくなるため，12ptよりも小さく出力されていることがわかりました．
\documentclass[12pt,a4paper]{jarticle}で指定した場合のように，紙のサイズがa4paperでかつ，本文中のフォントサイズが12ptになるようにするには，どうすればよかったのでしょうか？
フォーラムのほうで質問を探した限りではなかったようなので質問いたしました．よろしくお願いいたします．
コンパイルした手順
platex.exe -src -interaction=nonstopmode main.tex
dvipdfmx.exe main.dvi
jsclassesのクラスでgeometryパッケージを使う場合には特別な注意が必要です。以下の投稿を参照してください。
平岡です．
回答，ありがとうございました．
紙のサイズがA4判より大きくなっていたから，フォントサイズが12ptでも小さく見えてしまったのですね．
Z.R.さんのリンクから，
\usepackage{geometry}
\geometry{left=30mm,right=25mm,top=25mm,bottom=25mm}
の部分を
\usepackage[driver=dvipdfm,truedimen]{geometry}
\geometry{left=30truemm,right=25truemm,top=25truemm,bottom=25truemm}
に修正すると，紙のサイズがA4判でかつ，フォントサイズが12ptの求めたい形になりました．
Akira Kakutoさん，奥村先生，Z.R.さんありがとうございました．
回答，ありがとうございました．
紙のサイズがA4判より大きくなっていたから，フォントサイズが12ptでも小さく見えてしまったのですね．
Z.R.さんのリンクから，
\usepackage{geometry}
\geometry{left=30mm,right=25mm,top=25mm,bottom=25mm}
の部分を
\usepackage[driver=dvipdfm,truedimen]{geometry}
\geometry{left=30truemm,right=25truemm,top=25truemm,bottom=25truemm}
に修正すると，紙のサイズがA4判でかつ，フォントサイズが12ptの求めたい形になりました．
Akira Kakutoさん，奥村先生，Z.R.さんありがとうございました．
でびまるといいます。
ここにぶら下がってしまいますが jsclasses のように基本的なクラスファイルで、
長さの設定には true を使うとか geometry を使うにも注意が必要、というのが
FAQ になってることにやや疑問を感じていました。
最近(遅い!)オプション nomag, usemag のようなのが追加されたのを知りました。
現状は usemag がデフォルトのようですが、むしろ nomag をデフォルトにしてしまい、
色々な状況を納得の上で利用したい拘りのあるユーザーさんだけがエキスパートモードの
感じで usemag を使う、というのも良いように思うのですがどうでしょうか。
開発者側の方の考えをお聞かせいただければと思います。
元開発者です。
jsclassesについては，これ以外にも，\rm や \tt を動作不可にするなどの提案がなされたことがありましたが，今までjsclassesで作った文書がそのままでは動作しなくなるような変更には私は反対してきました。
nomagまたはnomag*についてはちょっと微妙ですが，今までの仕様を前提として作られた文書（たとえば本）が，重版時に組み直したら微妙に変わってしまうということがあるのならば，まずいと思います（編集者さんがネットで仕様変更についての最新情報を仕入れておられるとは限らないので）。
なにしろPKフォント全盛のときに作られたものですので，これ以外にも，今となってはおかしいところがいろいろあると思います。
一番いいのはjsclassesを塩漬けにして，新しい名前のもの（bxjsclsでもjlreqでもいいのですが）を作って，それを今後の標準にすることだと思うのですが，どうでしょう？（できればluatex-ja対応のものがいいかもしれません）。
jsclassesについては，これ以外にも，\rm や \tt を動作不可にするなどの提案がなされたことがありましたが，今までjsclassesで作った文書がそのままでは動作しなくなるような変更には私は反対してきました。
nomagまたはnomag*についてはちょっと微妙ですが，今までの仕様を前提として作られた文書（たとえば本）が，重版時に組み直したら微妙に変わってしまうということがあるのならば，まずいと思います（編集者さんがネットで仕様変更についての最新情報を仕入れておられるとは限らないので）。
なにしろPKフォント全盛のときに作られたものですので，これ以外にも，今となってはおかしいところがいろいろあると思います。
一番いいのはjsclassesを塩漬けにして，新しい名前のもの（bxjsclsでもjlreqでもいいのですが）を作って，それを今後の標準にすることだと思うのですが，どうでしょう？（できればluatex-ja対応のものがいいかもしれません）。
> nomagまたはnomag*についてはちょっと微妙ですが，
> 今までの仕様を前提として作られた文書（たとえば本）が，
> 重版時に組み直したら微妙に変わってしまうということが
> あるのならば，まずいと思います
は同意します。
> 一番いいのはjsclassesを塩漬けにして，新しい名前のもの
> （bxjsclsでもjlreqでもいいのですが）を作って，それを
> 今後の標準にすることだと思うのですが，どうでしょう？
> （できればluatex-ja対応のものがいいかもしれません）。
に対しては，私は少し違う見方をしています。
私は，「標準」（明文化されているか，単なるデファクトスタンダードなのか
は問わないことにします）の“名前”がどんどん変わっていくことに違和感を覚えます。
・19xx 年の標準は A という名前のクラス
・200x 年の標準は B という名前のクラス
・201x 年の標準は C という名前のクラス
と移り変わっていくのは，外から見ると分かりにくいと思います。
結局「名前が増えているだけ」で，移行する人はごく一部にすぎず，
むしろ混乱しそうです。
（pTeX と upTeX と LuaTeX の違いがわからない，とか，
jarticle と jsarticle のどちらを使えばいいの，みたいな状況に
拍車をかけるだけでは，と危惧しています）
もちろん，新しいクラス（bxjscls や jlreq）が増えていくことは好ましい
と思います。ただ，それを「標準」と名乗らせるべきかどうかに慎重です。
だからと言って，「jsclasses をバンバン変えて良い」とも私は思って
いませんのでご安心ください。
なお，
「jsclasses を変えなかったからといって，一切の組版結果が変わらない」
と考えるのは危険だ，という点は，何度か指摘が出ている通りです。
「\RequirePackage[2016/03/31]{platexrelease} しておけば一切の
pLaTeX の組版結果が変わらない」
と考えるのも同様に危険です。（本家 LaTeX にも，各種パッケージにも，
TeX や (e-)(u)pTeX 本体にも時々変更が入るため。）
> 今までの仕様を前提として作られた文書（たとえば本）が，
> 重版時に組み直したら微妙に変わってしまうということが
> あるのならば，まずいと思います
は同意します。
> 一番いいのはjsclassesを塩漬けにして，新しい名前のもの
> （bxjsclsでもjlreqでもいいのですが）を作って，それを
> 今後の標準にすることだと思うのですが，どうでしょう？
> （できればluatex-ja対応のものがいいかもしれません）。
に対しては，私は少し違う見方をしています。
私は，「標準」（明文化されているか，単なるデファクトスタンダードなのか
は問わないことにします）の“名前”がどんどん変わっていくことに違和感を覚えます。
・19xx 年の標準は A という名前のクラス
・200x 年の標準は B という名前のクラス
・201x 年の標準は C という名前のクラス
と移り変わっていくのは，外から見ると分かりにくいと思います。
結局「名前が増えているだけ」で，移行する人はごく一部にすぎず，
むしろ混乱しそうです。
（pTeX と upTeX と LuaTeX の違いがわからない，とか，
jarticle と jsarticle のどちらを使えばいいの，みたいな状況に
拍車をかけるだけでは，と危惧しています）
もちろん，新しいクラス（bxjscls や jlreq）が増えていくことは好ましい
と思います。ただ，それを「標準」と名乗らせるべきかどうかに慎重です。
だからと言って，「jsclasses をバンバン変えて良い」とも私は思って
いませんのでご安心ください。
なお，
「jsclasses を変えなかったからといって，一切の組版結果が変わらない」
と考えるのは危険だ，という点は，何度か指摘が出ている通りです。
「\RequirePackage[2016/03/31]{platexrelease} しておけば一切の
pLaTeX の組版結果が変わらない」
と考えるのも同様に危険です。（本家 LaTeX にも，各種パッケージにも，
TeX や (e-)(u)pTeX 本体にも時々変更が入るため。）
> 今までの仕様を前提として作られた文書（たとえば本）が，
> 重版時に組み直したら微妙に変わってしまうということが
> あるのならば，まずいと思います
たしかに互換性は大切ですね。
一方で、業務で安全を求めるのなら、
初版時に使ったバージョンのクラスファイルを維持しておいて、
重版時に組み直す際にはそれを使う、というのもよさそうです。
## 実は、まさにその理由で、
## いまだに2000年の頃のpLaTeXをメインで使っています。
## もう少し新しい環境もお試し用に入れてはあって、
## 他の人と共同作業するときなどにはそっちを使うこともありますが。
みなさんが自衛策を講じていると期待できるなら、
標準のものが変節するということも、あってよいかもしれません。
> 重版時に組み直したら微妙に変わってしまうということが
> あるのならば，まずいと思います
たしかに互換性は大切ですね。
一方で、業務で安全を求めるのなら、
初版時に使ったバージョンのクラスファイルを維持しておいて、
重版時に組み直す際にはそれを使う、というのもよさそうです。
## 実は、まさにその理由で、
## いまだに2000年の頃のpLaTeXをメインで使っています。
## もう少し新しい環境もお試し用に入れてはあって、
## 他の人と共同作業するときなどにはそっちを使うこともありますが。
みなさんが自衛策を講じていると期待できるなら、
標準のものが変節するということも、あってよいかもしれません。
> 商業出版での重版では互換性云々のレベルでなく，
> まったく同じ組結果でなくてならないので，
> クラス，パッケージだけに留まらず処理した
> ディストリビュージョンやシステムまるごと保全してます．
ありがとうございます。私も知人からそのように聞いたことがあります。
> （本家 LaTeX にも，各種パッケージにも，
> TeX や (e-)(u)pTeX 本体にも時々変更が入るため。）
と上で私がコメントしたのも，背景にはそれがあります。
多分，いま一番問題があるとすれば，LaTeX やクラスファイルの互換性云々
ではなくて，何らかの理由で
「特定の古い TeX ディストリビューションを使用したい」
場合に，それをインストールする方法が Web 上にほとんどないこと，だと
思っています。一応，それに該当する数少ないドキュメントを貼っておきます：
https://qiita.com/munepi/items/44117be9180ac7a86d82
http://d.hatena.ne.jp/acetaminophen/20160518/1464009588
> まったく同じ組結果でなくてならないので，
> クラス，パッケージだけに留まらず処理した
> ディストリビュージョンやシステムまるごと保全してます．
ありがとうございます。私も知人からそのように聞いたことがあります。
> （本家 LaTeX にも，各種パッケージにも，
> TeX や (e-)(u)pTeX 本体にも時々変更が入るため。）
と上で私がコメントしたのも，背景にはそれがあります。
多分，いま一番問題があるとすれば，LaTeX やクラスファイルの互換性云々
ではなくて，何らかの理由で
「特定の古い TeX ディストリビューションを使用したい」
場合に，それをインストールする方法が Web 上にほとんどないこと，だと
思っています。一応，それに該当する数少ないドキュメントを貼っておきます：
https://qiita.com/munepi/items/44117be9180ac7a86d82
http://d.hatena.ne.jp/acetaminophen/20160518/1464009588
もう少し，今の個人的な考えを書いておきます：
> 新しい名前のもの（bxjsclsでもjlreqでもいいのですが）を作って，
> それを今後の標準にすることだと思うのですが，どうでしょう？
> （できればluatex-ja対応のものがいいかもしれません）。
これを仮にやるのであれば，
[1] 少なくとも pLaTeX / upLaTeX / LuaTeX-ja の全てで動くもの
でないと，モチベーションが起こらないです（少なくとも私は）。
＃ pLaTeX / upLaTeX は十分に枯れていて，新しい「標準」クラスに
＃ 移行する人が少なそう → 使われないものを作っても意味がない。
あと，
[2] 既存のクラスを標準としてしまうのも怪しい
と思っています。bxjscls は「jsclasses を極力踏襲したもの」，
jlreq は「JLReq（日本語組版処理の要件）に極力準拠したもの」という
意図がすでに名前に現れているように思います。
これが「標準」と完全一致するかどうか，精査してからでないと破綻しそうです。
以上を踏まえると，
「新しい名前を決めて，標準とは何かを定めるところから始めて，
新しいクラスを作っていく」という方向であれば，可能性はあると思います。
（あくまで個人的な考えです）
> 新しい名前のもの（bxjsclsでもjlreqでもいいのですが）を作って，
> それを今後の標準にすることだと思うのですが，どうでしょう？
> （できればluatex-ja対応のものがいいかもしれません）。
これを仮にやるのであれば，
[1] 少なくとも pLaTeX / upLaTeX / LuaTeX-ja の全てで動くもの
でないと，モチベーションが起こらないです（少なくとも私は）。
＃ pLaTeX / upLaTeX は十分に枯れていて，新しい「標準」クラスに
＃ 移行する人が少なそう → 使われないものを作っても意味がない。
あと，
[2] 既存のクラスを標準としてしまうのも怪しい
と思っています。bxjscls は「jsclasses を極力踏襲したもの」，
jlreq は「JLReq（日本語組版処理の要件）に極力準拠したもの」という
意図がすでに名前に現れているように思います。
これが「標準」と完全一致するかどうか，精査してからでないと破綻しそうです。
以上を踏まえると，
「新しい名前を決めて，標準とは何かを定めるところから始めて，
新しいクラスを作っていく」という方向であれば，可能性はあると思います。
（あくまで個人的な考えです）
デフォルトのフォントが Computer Modern のままで nomag をデフォルトにすると，10pt以外での組版結果がひどいことになるので，避けた方がよいかと思います。
でびまるです。
最初に nomag, usemag を見付けたのが実は上のサイトでした(お世話になりました)。オプションの違いを見易くしてるとは思いましたが「組版結果がひどい」とまでは感じませんでした。
あえて言うなら17pt で数式記号のバランスが悪いですがこれは普通に TeX の FAQ に思えますし、昔なら foiltex、今なら beamer の守備範囲な気もしますがどうでしょうか。
ひどいかどうかは主観によるでしょうが，私なら，本文中のデフォルトの英数字が cmr8 や cmr12 といった組版は耐えがたいですね……。
あと，usemag / nomag は，貼り込まれる画像の寸法など，別の影響が生じる点にも注意が必要です。
例えば
\documentclass[dvipdfmx,8pt,nomag]{jsarticle}
\usepackage{graphicx}
\begin{document}
ほげ\includegraphics{hoge.pdf}ほげ
\end{document}
の場合，nomag / usemag で，hoge.pdf の貼り込まれる寸法が変わり，組版結果が大きく変わることになります。
あと，usemag / nomag は，貼り込まれる画像の寸法など，別の影響が生じる点にも注意が必要です。
例えば
\documentclass[dvipdfmx,8pt,nomag]{jsarticle}
\usepackage{graphicx}
\begin{document}
ほげ\includegraphics{hoge.pdf}ほげ
\end{document}
の場合，nomag / usemag で，hoge.pdf の貼り込まれる寸法が変わり，組版結果が大きく変わることになります。