سلام.
خواهشمندم مسیر ها و نام فونت ها را خلاصه سازی نماید.
مسیرهای ساخته شده برای دستیابی به فونت ها طولانی هستند.
اگر مسیر پروژه هایی که از فونت شما استفاده میکنند، خود نیز طولانی باشد، بسته به سیستم عامل، مرورگرها رفتارهای متفاوتی دارند.
بطور مثال در ویندوز حداکثر طول قابل تشخیص برای مسیرهای ختم شده به یک فایل، شامل نام درایو، نام پوشه ها، نام فایل، و کاراکترهای جدا کننده، 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 کاراکتر شوند، فونت ها را بارگذاری نمیکند.
اگر لطف کنید و ساختار پوشه های حاوی فونت ها را ساده سازی و کوتاه کنید این مشکل اتفاق نخواهد افتاد.
خواهشمندم به این موضوع بیاندیشید.
توسعه دهندگان میتوانند چنین ساختاری را پیاده کنند ولی هر زمان که نسخه جدید فونت ارائه شود، میبایست این ساختار را مجددا ایجاد کنند که کار پر دردسر و خطا افزایی میباشد.
میتوانید همین نسخه را با بدون تغییر در فونت ها، با یک شماره ریویو (بطور مثال 33.0.3-rev1)، در npm مجددا منتشر نمایید.
شماره ریویو با استاندارد SemVer 2.0 تطابق دارد و در npm پشتیبانی میشود.
سلام. خواهشمندم مسیر ها و نام فونت ها را خلاصه سازی نماید. مسیرهای ساخته شده برای دستیابی به فونت ها طولانی هستند. اگر مسیر پروژه هایی که از فونت شما استفاده میکنند، خود نیز طولانی باشد، بسته به سیستم عامل، مرورگرها رفتارهای متفاوتی دارند.
بطور مثال در ویندوز حداکثر طول قابل تشخیص برای مسیرهای ختم شده به یک فایل، شامل نام درایو، نام پوشه ها، نام فایل، و کاراکترهای جدا کننده، 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 کاراکتر شوند، فونت ها را بارگذاری نمیکند. اگر لطف کنید و ساختار پوشه های حاوی فونت ها را ساده سازی و کوتاه کنید این مشکل اتفاق نخواهد افتاد.
بطور مثال چنین ساختاری را ملاحظه بفرمایید:
در هر پوشه حاوی یک نسخه متفات نیز ساختار بدین شکل خواهد بود:
حتی میتوانید اسامی فایل ها را نیز کوتاه تر بنویسید:
خواهشمندم به این موضوع بیاندیشید. توسعه دهندگان میتوانند چنین ساختاری را پیاده کنند ولی هر زمان که نسخه جدید فونت ارائه شود، میبایست این ساختار را مجددا ایجاد کنند که کار پر دردسر و خطا افزایی میباشد. میتوانید همین نسخه را با بدون تغییر در فونت ها، با یک شماره ریویو (بطور مثال 33.0.3-rev1)، در npm مجددا منتشر نمایید. شماره ریویو با استاندارد SemVer 2.0 تطابق دارد و در npm پشتیبانی میشود.