vazirmatn
vazirmatn copied to clipboard
کوتاه سازی مسیرهای منتهی به فونت ها
سلام. خواهشمندم مسیر ها و نام فونت ها را خلاصه سازی نماید. مسیرهای ساخته شده برای دستیابی به فونت ها طولانی هستند. اگر مسیر پروژه هایی که از فونت شما استفاده میکنند، خود نیز طولانی باشد، بسته به سیستم عامل، مرورگرها رفتارهای متفاوتی دارند.
بطور مثال در ویندوز حداکثر طول قابل تشخیص برای مسیرهای ختم شده به یک فایل، شامل نام درایو، نام پوشه ها، نام فایل، و کاراکترهای جدا کننده، 260 کاراکتر میباشد و برای فعال سازی مسیرهای طولانی تر، باید Registry ویندوز دست کاری شود که خب هر کاربری دانش این کار را ندارد. سند رسمی از مایکروسافت Maximum Path Length Limitation
به تصویر ذیل توجه فرمایید: بنده قصد دارم پکیج npm رسمی قلم شما را به پروژه ای بیافزایم. برای نسخه RD-UI-FD-NL که مناسب ترین نسخه برای نرم افزارهای مبتنی بر وب میباشد، طول مسیر از پوشهء ریشه پروژه برابر است با: 26 + (10+1) + (4+1) + (25+1) + (5+1) + (8+1) + 38 = 121 کاراکتر. فرض کنید آدرس پوشه پروژه بنده نیز به دلیل تو در تویی پوشه هایی که جهت طبقه بندی پروژه بکار برده ام، دارای طولی بیش از 140 کاراکتر باشد. در نتیجه به طول 261 میرسیم و مرورگرهای مبتنی بر ویندوز، همه شان، فایل فونت را در اجرای local تشخیص نمیدهند. بنابراین امثال بنده مجبور میشوند آدرس های پروژه های شان را روی استوریج محلی طوری تنظیم کنند که این مشکل پیش نیاید. این مسئله شاید در پروژه های شخصی به راحتی انجام شود ولی در پروژه های سازمانی، دیسیپلین های کدنویسی ممکن است مانع این موضوع باشد.
ممکن است شما بفرمایید که چه ربطی دارد، آدرس دهی در مرورگر به صورت نسبی تنظیم میشود که فرمایش صحیحی است، البته به شرطی که پروژه مبتنی بر یک نرم افزار وب-سرور محلی سرو شود. اگر فایل html مربوطه را مستقیم (با دابل کلیک یا درگ اند دراپ) در مرورگر اجرا کنیم، مرورگر، آدرس های نسبی فونت ها را بر اساس آدرس فیزیکی فایل html روی استوریج محلی، میسازد و اگر این آدرس ها بیش از 260 کاراکتر شوند، فونت ها را بارگذاری نمیکند. اگر لطف کنید و ساختار پوشه های حاوی فونت ها را ساده سازی و کوتاه کنید این مشکل اتفاق نخواهد افتاد.
بطور مثال چنین ساختاری را ملاحظه بفرمایید:
Root
│ AUTHORS.txt
│ CHANGELOG.md
│ OFL.txt
│ README.md
│ راهنما.txt
└───dist
├───base
│ ├───ttf
│ ├───var
│ └───web
├───misc
│ ├───FD
│ │ ├───ttf
│ │ ├───var
│ │ └───web
│ ├───FDNL
│ │ ├───ttf
│ │ ├───var
│ │ └───web
│ └───NL
│ ├───ttf
│ ├───var
│ └───web
├───UI
│ ├───base
│ │ ├───ttf
│ │ ├───var
│ │ └───web
│ └───misc
│ ├───FD
│ │ ├───ttf
│ │ ├───var
│ │ └───web
│ ├───FDNL
│ │ ├───ttf
│ │ ├───var
│ │ └───web
│ └───NL
│ ├───ttf
│ ├───var
│ └───web
└───RD
├───base
│ ├───ttf
│ ├───var
│ └───web
├───misc
│ ├───FD
│ │ ├───ttf
│ │ ├───var
│ │ └───web
│ ├───FDNL
│ │ ├───ttf
│ │ ├───var
│ │ └───web
│ └───NL
│ ├───ttf
│ ├───var
│ └───web
└───UI
├───base
│ ├───ttf
│ ├───var
│ └───web
└───misc
├───FD
│ ├───ttf
│ ├───var
│ └───web
├───FDNL
│ ├───ttf
│ ├───var
│ └───web
└───NL
├───ttf
├───var
└───web
در هر پوشه حاوی یک نسخه متفات نیز ساختار بدین شکل خواهد بود:
base
│ AtFontFace.css
├───ttf
│ 100-Thin.ttf
│ 200-ExtraLight.ttf
│ 300-Light.ttf
│ 400-Regular.ttf
│ 500-Medium.ttf
│ 600-SemiBold.ttf
│ 700-Bold.ttf
│ 800-ExtraBold.ttf
│ 900-Black.ttf
├───var
│ wght.ttf
└───web
100-Thin.woff2
200-ExtraLight.woff2
300-Light.woff2
400-Regular.woff2
500-Medium.woff2
600-SemiBold.woff2
700-Bold.woff2
800-ExtraBold.woff2
900-Black.woff2
wght.woff2
حتی میتوانید اسامی فایل ها را نیز کوتاه تر بنویسید:
base
│ vmaff.css
├───ttf
│ 100.ttf
│ 200.ttf
│ 300.ttf
│ 400.ttf
│ 500.ttf
│ 600.ttf
│ 700.ttf
│ 800.ttf
│ 900.ttf
├───var
│ wght.ttf
└───web
100.woff2
200.woff2
300.woff2
400.woff2
500.woff2
600.woff2
700.woff2
800.woff2
900.woff2
wght.woff2
خواهشمندم به این موضوع بیاندیشید. توسعه دهندگان میتوانند چنین ساختاری را پیاده کنند ولی هر زمان که نسخه جدید فونت ارائه شود، میبایست این ساختار را مجددا ایجاد کنند که کار پر دردسر و خطا افزایی میباشد. میتوانید همین نسخه را با بدون تغییر در فونت ها، با یک شماره ریویو (بطور مثال 33.0.3-rev1)، در npm مجددا منتشر نمایید. شماره ریویو با استاندارد SemVer 2.0 تطابق دارد و در npm پشتیبانی میشود.