نسخه آزمایشی (بتا 1) لیبره آفیس 6.3 که شامل برخی بهبودها در رابط گرافیکی کاربر، کارایی بهتر دخیره و بازیابی فایل‌ها و برخی ارتقاءهای دیگر است منتشر شد.
برای دیدن مشخصات کامل نسخه آزمایشی (بتا 1) لیبره آفیس 6.3 به یادداشت‌های انتشار لیبره‌آفیس 6.3 در ویکی مراجعه کرده یا لیبره آفیس 6.3 بتا 1 را دانلود کنید.
در این نسخه بیشتر مشکلات چینش کامل متن (justifed text) در نمایش حل شده، اما در خروجی مستقیم PDF کماکان مشکلات وجود دارد. یک راه حل مقطعی، استفاده از پرینترهای PDF جداگانه برای تولید خروجی است.
نسخه جدید لیبره آفیس (6.2) با ویژگی‌های جدید گرافیکی منتشر شد. این نسخه هماهنگی بیشتری با دسکتاپ‌های KDE و LXQT دارد و برای نمایشگرهای با تفکیک‌پذیری بالا (HiDPI) بهینه‌سازی شده است.
برای دانلود نسخه جدید لیبره آفیس این‌جا کلیک کنید.
با توجه به آسیب‌پذیری‌های موجود در نسخه‌های قبل، بنیاد مستندات توصیه کرده است که همه کاربران لیبره آفیس خود را به نسخهٔ 6.0.7 و یا 6.1.3 به‌روز کنند.
برای دریافت جدیدترین نسخه لیبره‌آفیس می‌توانید به آدرس زیر مراجعه کنید:
https://fa.libreoffice.org/download/
نسخه به روز شده، امنیت و پایداری بهتری نسبت به نسخه‌های قبلی دارد.
نسخه 5.3 لیبره‌آفیس مدتی پیش منتشر شده است. این نسخه یک ویژگی بسیار مهم دارد و آن هم حل مشکل چینش کامل متن (full justify) می‌باشد که پیش از این دچار مشکلات متعدد بود و خروجی چه در چاپ و چه در فایل PDF تولید شده ظآهر غیرقابل قبولی داشت.
شما می‌توانید جدیدترین نسخه لیبره‌آفیس را از آدرس زیر دانلود کنید:
http://fa.libreoffice.org/download/
در فهرست باگ‌های لیبره‌آفیس این باگ به صورت مشکل حل شده ثبت شده که از نسخه 5.3 حل مشکل در اختیار استفاده کنندگان از لیبره‌آفیس نسخه پایدار قرار گرفته است.
در فهرست تغییرات لیبره آفیس 5.3 توضیحاتی به شرح زیر آمده است:
The Graphite font Awami Nastaliq used on macOS with the new layout engine
STIX Two Text font showing small caps, proportional numbers, and fractions activated
New vertical left-to-right option for text direction
Vertical left-to-right text layout used for traditional Mongolian
یکی از مفاهیم جالب و در عین حال پیچیده در دنیای نرم‌افزار (گرچه در سایر علوم هم کاربرد دارد)، مفهوم باگ (Bug) یا به طور ساده نقص نرم‌افزاری است. احتمالا می‌دانید به اشکالات نرم‌افزاری اصطلاحا باگ اطلاق می‌شود ولی واقعا چرا نرم‌افزارها باگ دارند؟ و چرا هیچ وقت شر این باگ‌ها حتی با ارائه انواع و اقسام آپدیت‌ها از سر ما کم نمی‌شود؟ مفهوم باگ، این واقعیت مهم را برای انسان روشن کرده است که هیچ فرمول و قانون مخلوق دست انسان، بی اشکال و کمبود نیست و در هر طرح و برنامه‌ای بدون تردید نقصان‌ها و لغزش‌هایی وجود دارد که در نگاه اول به نظر نرسیده‌اند. رفع باگ‌ها تقریبا مثل حل کردن معماست و برای بسیاری از برنامه‌نویسان یکی از قسمت‌های چالش برانگیز و لذت‌بخش کار است.
باگ از نظر لغوی یعنی حشره کوچک و در تاریخ مهندسی نرم‌افزار گفته می‌شود این اصطلاح را اولین بار گریس هوپر خانمی که در دانشگاه هاروارد مشغول تحصیل و تحقیق در رشته کامپیوتر بود، به کار برده است. او در حال کار با کامپیوتر یک بار با مشکل مواجه شد و تکنسین‌هایی که برای بررسی مشکل و تعمیر کامپیوتر، آن را باز کرده بودند سوسکی را پیدا کردند که وارد دستگاه شده بود و آن را از کار انداخته بود و بدین ترتیب اولین بار واژه باگ به شوخی مورد استفاده قرار گرفت. اعتقاد بر این است که اصطلاح Debugg (اشکال‌زدایی) نیز توسط همین افراد ابداع شد.
باگ اشکالی است که در یک برنامه رخ داده و باعث از کار انداختن کلی آن یا اجرا نکردن دستور یا دستورات بعدی به صورت ناقص یا کامل می‌گردد. اغلب این مشکلات در هنگامی رخ می‌دهد که داده‌های دریافتی از سوی کاربر فیلتر نشده و برنامه سعی به اجرا کردن آن می‌کند برای نمونه می‌توان انجام عمل تقسیم را بیان کرد. فکر کنید برنامه دو متغیر را دریافت می‌کند به طوری که متغیر اول عدد صورت و متفیر دوم عدد مخرج می‌باشد اگر کاربر ابتدا عدد ۶ و سپس عدد ۳ را وارد کند برنامه در خروجی خود عدد ۲ را نمایش خواهد داد حال اگر کاربر در صورت یک عدد (مثلا ۶) و در مخرج یک حرف الفبا یا عدد صفر را وارد کند به نظر شما عکس‌العمل برنامه چه خواهد بود؟
همانطور که می‌دانیم در ریاضیات تقسیم عدد بر حروف الفبا و صفر تعریف نشده است پس برنامه با حالتی از پیش تعریف نشده برخورد می‌کند و چون قابلیت اجرا کردن آنها را ندارد هنگ می‌کند و خروجی منطقی را تحویل نمی‌دهد.
یکی از راه‌های مفید در همراهی و کمک به تیم توسعه‌دهنده نرم‌افزارهای مورد علاقه بخصوص اگر دانش و فرصت کافی برای شرکت در سایر روش‌های همکاری در دسترس نباشد، استفاده از نرم‌افزار و سپس گزارش باگ‌های موجود در آن به صورت حرفه‌ای هست. اما یک گزارش باگ بهینه و حرفه‌ای چه خصوصیاتی دارد؟
در ادامه با مجموعه اصولی که توسعه‌دهندگان توزیع لینوکسی elementary OS برای گزارش‌های باگ‌ها وضع کرده‌اند آشنا می‌شویم.
اول از همه اطمینان حاصل کنید که باگ مورد نظر شما پیش از آن گزارش نشده است، گزارش دو و گاهی چندباره باگ‌ها از سوی کاربران مختلف باعث اتلاف وقت سایر کاربران و توسعه‌دهندگان و پر کردن انجمن‌ها، لیست‌های پستی و… از موضوعات تکراری، و غیرمتمرکز می‌شود. معمولا در یک گزارش باگ راهی برای اعلام اینکه شما نیز با آن باگ مواجه شده‌اید وجود دارد و نیازی به ارسال دوباره گزارش باگ نیست.
برای باگ خود عنوان دقیقی انتخاب نمائید. این کار باعث تسهیل کار توسعه‌دهندگان نرم‌افزار در جستجو و مرور لیست باگ‌ها می‌شود. عنوانی مانند «نرم‌افزار X کرش می‌کند» به دلیل ابهام موجود در آن مناسب نیست. عبارتی مانند «عملکرد را بهبود دهید» نیز دردی دوا نخواهد کرد. یک عنوان خوب می‌تواند چیزی شبیه این باشد: «زمانی که فرآیند X به پایان می‌رسد پیامی نمایش داده نمی‌شود».
شاید این توصیه شبیه توصیه شماره ۲ باشد، اما اگر تمایل دارید که مشکل یا باگی را گزارش دهید مهم است که بدانید باید حتی‌الامکان کمّی صحبت کنید. اگر نمی‌توانید برای گزارش باگ خود از اعداد و ارقام مقایسه‌ای استفاده کنید، سعی نمائید آنچه با آن مواجه شده و مشاهده کرده‌اید را دقیقا توضیح دهید. برای مثال نگوئید «X خوب کار نمی‌کند» یا «X عملکرد مناسبی ندارد». به جای آن تلاش کنید که توضیح دهید چه اتفاقی رخ داده است و در مقابل شما انتظار چه رخدادی را داشته‌اید. برای مثال: «پنل به جای اینکه به نرمی و با اجرای افکت باز شود، ناگهان ظاهر می‌شود». سخن آخر اینکه مشکل را به گونه‌ای گزارش دهید که ملموس و کاربردی باشد.
یکی از مهمترین جنبه‌های یک گزارش باگ یا اشکال این است که توسعه‌دهنده باید بتواند از روی آن گزارش، موقعیت و مشکل مورد نظر را بازسازی نماید. بدین منظور شما باید اطلاعات مرتبط نظیر نسخه سیستم‌عامل (یا نرم‌افزار) خود، نسخه کتابخانه‌های مرتبط نظیر Gtk یا WebKit و هرگونه تغییر و دخل و تصرف در سیستم مثل تغییر در مدیر پنجره یا کرنل را ضمیمه گزارش خود نمائید. اگر می‌خواهید یک کرش (Crash) را گزارش دهید لازم است که backtrace را نیز به گزارش خود اضافه نمائید.
با اینحال باید توجه داشته باشید که بهتر است گزارش شما خلاصه نیز باشد. از طولانی کردن گزارش خود و ارائه اطلاعات بی ارتباط با آن خودداری نمائید.
اگر گزارش شما دارای اطلاعات کافی برای بازتولید اشکال از سوی توسعه‌دهندگان نباشد، معمولا برچسب ناقص (Incomplete)* بر آن می‌خورد. در اغلب موارد یک توسعه‌دهنده از طریق یک نظر درخواست اطلاعات اضافی خاصی را خواهد کرد. اگر چنین اطلاعاتی از سوی شما ارائه نگردد، گزارش شما نهایتا بدون حصول نتیجه منقضی خواهد شد.
اگر شما گزارش باگ خود را به اشتباه در صفحه نرم‌افزار دیگری گزارش دهید، گزارش شما برچسبی مانند (Invalid) خواهد خورد. در چنین مواردی گاهی توسعه‌دهندگان در صورت شناسایی نرم‌افزار مورد نظر شما، خود راسا اقدام به انتقال گزارش مربوطه در صفحه نرم‌افزار مرتبط خواهند کرد در غیر این صورت شما خود باید نرم‌افزار مورد نظر خود را یافته و گزارش باگ خود را ارسال نمائید.
اگر هدف شما از گزارش درخواست یک امکان یا ویژگی جدید باشد توسعه‌دهنده گزارش شما را با برچسب Opinion یا Won’t Fix مشخص خواهد کرد. توسعه‌دهندگان معمولا برای صحبت در مورد چنین مسائلی در دسترس و پاسخگو هستند اما بهتر است آنها را به خاطر برچسب‌هایی که به گزارش شما می‌زنند مورد شماتت قرار ندهید.
تمام گزارش باگ‌ها، گزارش باگ نیستند! گاهی کاربر به اشتباه تصور می‌کند که باگی را در نرم‌افزار کشف کرده در حالی که در بسیاری از موارد مشکل ناشی از عدم آشنایی کاربر با نرم‌افزار بوده است و نه وجود باگ در آن. تشخیص اینکه گزارش باگ ناشی از وجود یک باگ واقعیست یا نه بر عهده توسعه‌دهندگان است؛ بنابراین اگر اشکالی که دیگران گزارش کرده‌اند برای شما نیز وجود دارد می‌توانید آن را نشان‌دار کنید. اما در هر حال شما نباید به جای توسعه‌دهندگان گزارش باگ دیگران را مورد تائید قرار دهید. این گزاره در رابطه با گزارش باگ‌های خودتان نیز صحیح است یعنی حتی اگر ۱۰۰٪ نسبت به درستی گزارش خود اطمینان دارید، درست نیست که خودتان گزارش خود را تائید کنید. توسعه‌دهندگان در فرصت مناسب، خود گزارش باگ‌ها را بررسی و در صورت صحت، آنها را تائید خواهند کرد.
قبل از این هم تا حدودی به این نکته اشاره شد اما خوب است دوباره تذکر داده شود که باید از نوشتن نظراتی با مضامینی نظیر «این مشکل برای من هم پیش آمده» خودداری کرد. این کار روند رهگیری حل مشکل را بر هم ریخته و دنبال کردن منطقی مطالب و سوال و جواب‌ها را برای همه با مشکل مواجه می‌کند. تنها زمانی به اظهار نظر بپردازید که بخواهید اطلاعات مرتبطی که در فرآیند حل مساله و پیدا کردن ریشه آن ارزشمند هستند را ارائه کنید. اگر قصد دارید به توسعه‌دهندگان بفهمانید که این مشکل برای شما نیز رخ داده است از لینک‌ها یا دکمه‌هایی که با مضمون «این مشکل برای من نیز رخ داده است» استفاده کنید.
* توجه داشته باشید که اصل این راهنمایی برای کاربران لینوکس elementary OS نگارش شده است بنابراین ممکن است این برچسب‌ها در سایر نرم‌افزارها یا پروژه‌ها متفاوت بوده و یا با واژه‌های دیگری نام‌گذاری شده باشند. اما در هر صورت اصول کار یکسان است.
منبع: وبلاگ علی حسین‌زاده
نسخه 5.1 لیبره‌آفیس منتشر شد. شما می‌توانید از آدرس زیر این نسخه جدید را دریافت و نصب کنید:
http://fa.libreoffice.org/download/
اگر می‌خواهید از رابط کاربری ترجمه شده به زبان فارسی استفاده کنید، روی «رابط کاربری ترجمه شده» کلیک کنید. علاوه بر نصب کننده اصلی باید فایل‌هائی که از این طریق دریافت می‌کنید نصب کنید تا بتوانید رابط کاربری ترجمه شده به زبان فارسی را ببینید.
نسخه 5 لیبره‌آفیس مدتی است که منتشر شده است. شما می‌توانید از آدرس زیر این نسخه جدید را دریافت و نصب کنید:
http://fa.libreoffice.org/download/
اگر می‌خواهید از رابط کاربری ترجمه شده به زبان فارسی استفاده کنید، روی «رابط کاربری ترجمه شده» کلیک کنید. علاوه بر نصب کننده اصلی باید فایل‌هائی که از این طریق دریافت می‌کنید نصب کنید تا بتوانید رابط کاربری ترجمه شده به زبان فارسی را ببینید.